[erlang-bugs] bogus 'unsafe variable' warning with try-else

[Raimo Niskanen]

On Thu, Nov 20, 2014 at 02:37:52PM +0100, Pierre Fenoll wrote:
> I guess the best option (and the one intended by OP) is to file:close/1 as
> soon as possible.
> 
> Thus Anthony's proposition would be unsuitable (though valid) and OP would
> need something like Kostis' case proposition.
> 
> I don't get why the scoping rules differ between try…after and case…of. I
> don't think they should (but I am surely missing an edge case where the
> difference makes sense).

Let's take a general try..end construct:

    try f()
    of
    	{ok,A} ->
	    B = {a,A};
	{error,A} ->
	    C = {r,A}
    catch
        error:Error ->
	    {error,Error};
	exit:Exit ->
	    {exit,Exit}
    after
	G = {A,B,C,Error,Exit} % which bound?
    end,
    {A,B,C,Error,Exit,G} % which bound?

Now, which variables should be bound in the after..end section,
and which should be bound after the end?

It would be nice if A was safe somwhere after the of..catch
section just as for the of..end section in case constructs, but since we
might get an exception anywhere we might not have bound A neither when
reaching any clause in the catch..after section, nor the after..end
section and certainly not after the end.  The only safe binding could be
the variable G since the after..end section is always executed.

So variables from the after..end section could have been exported, but not
any other.  But in that special case below withount a catch..after section
the case construct rules could hold.  There might be other special cases.
But for the sake of consistency the simplest rule is that no variables are
exported from the try..end construct.

/ Raimo Niskanen

> 
> 
> Cheers,
> -- 
> Pierre Fenoll
> 
> 
> On 20 November 2014 14:22, Kostis Sagonas <kostis@REDACTED> wrote:
> 
> > On 11/20/14 15:13, Anthony Ramine wrote:
> >
> >> try file:read(F, 1024 * 1024) of
> >>      {ok,Bin} -> binary_to_term(Bin)
> >> after
> >>      file:close(F)
> >> end
> >>
> >
> >
> > And the reason to _having_ to write this is?  (*)
> >
> > Cheers,
> > Kostis
> >
> > (*) Less bugs are exposed in the compiler and less baby cats die in China
> > if we all write like that, perhaps? :)
> >
> > Jokes aside, I also agree the above code is nicer, but that does not mean
> > that the current warning is bogus and the analysis should be fixed.
> >
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugs@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-bugs
> >

> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs


-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB