[erlang-questions] Erlang dialyzer warnings for internal functions.

WW kingwang98@REDACTED
Mon Apr 29 09:00:29 CEST 2019

Thank you, Guilhenrme!
Here is my conclusion:
For internal function call, we need actually implement to cover all cases specified in the function (missing implementation dialyzer will give warning), however, when exporting that function, dialyzer  can't determine the full range of possible arguments, so it will not give warning. 
solution:  1) Export that function.                2) Switch off  thedialyzer warning for that function: -dialyzer({nowarn_function, validator/1}).

Best regards //Wei. W
    On Sunday, April 28, 2019, 11:19:26 PM GMT+2, Guilherme Andrade <g@REDACTED> wrote:  
 Hello Wei,

On Sun, 28 Apr 2019 at 21:38, WW <kingwang98@REDACTED> wrote:

Why dialyzer did not complain when  I  exported the function validator/1 ?
It means exported function allowing never reach the calls ?

Because when you export said function, Dialyzer can't assume it won't be called from code outside its analysis scope (e.g. modules in uncovered apps, modules loaded in runtime, function references generated in run time, the shell, ..) and so it can't determine the full range of possible arguments - anything goes. And if anything goes, there's no way of saying: "this particular execution flow will never happen."
Which is usually not the case with internal functions, where all possible calling arguments /may/ be known when performing analysis, depending on your code and how precisely Dialyzer can track type constraints in it.


   On Sunday, April 28, 2019, 9:30:03 PM GMT+2, Kostis Sagonas <kostis@REDACTED> wrote:  
 On 4/28/19 6:41 PM, WW wrote:
> What is the best solution to avoid dialyzer warnings meanwhile also 
> satisfy my use cases.?

One cannot really answer this question without knowing what your "use 
case(s)" really is.,,,

If it really is the code example you posted, if you pay close attention 
to the warning that you get from dialyzer, dialyzer also tells you that 
the call validator([]), let alone validator(3), is actually unreachable 
code in your example.  This is because dialyzer discovers that the prior 
call (validator(undefined)) will throw an exit exception and 
control-flow will never reach the validator([]) (and validator(3)) calls.

Once again, remember the slogan: "Dialyzer is never wrong."

erlang-questions mailing list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190429/9cdfd75c/attachment.htm>

More information about the erlang-questions mailing list