[erlang-bugs] try in shell

[Richard Carlsson]

On Wed, Sep 17, 2014 at 1:50 PM, Tony Rogvall <tony@REDACTED> wrote:

>
> On 17 sep 2014, at 00:46, Daniel Luna <daniel@REDACTED> wrote:
>
> The errors from compilation is about the *statement*, not the full
> function. The statement will result in an arithmetic error even if the
> function won't.
>
> Well. I think that is up for an argument. The compiler is "smart" enough
> to see that the code will result in an arithmetic exception
> but not even smart enough to see that it is caught?
>

I like to call them subexpressions, not statements (this ain't C), but yes.
It's easy to check every subexpression to see if it can be evaluated
statically, and in that case, if it would definitely fail. To see that it
would be caught requires also tracking the execution context for each
subexpression and not reporting the failing code, not all that difficult
but slightly messy.

   /Richard


>
> Regards,
>
> Daniel
> On Sep 16, 2014 6:18 PM, "Tony Rogvall" <tony@REDACTED> wrote:
>
>> Hi!
>>
>> Not sure how this is supposed to be, given that there is a shell function
>> called catch_exception/1.
>>
>> Running in 17.1 (approx)
>>
>> > try throw(x) catch Class:Reason -> {Class,Reason} end.
>> {throw,x}
>>
>> > try exit(2) catch Class:Reason -> {Class,Reason} end.
>> * exception exit: 2
>>
>> > try foo:bar() catch Class:Reason -> {Class,Reason} end.
>> * exception error: undefined function erl_eval:expr/3
>>
>> > try 1/0 catch Class:Reason -> {Class,Reason} end.
>> * exception error: an error occurred when evaluating an arithmetic
>> expression
>>
>> > try (a=b) catch Class:Reason -> {Class,Reason} end.
>> * exception error: no match of right hand side value b
>>
>> Putting the above try expression in a module:
>>
>> -module(tryme).
>> -compile(export_all).
>>
>> test1() ->
>>     try throw(x) catch Class:Reason -> {Class,Reason} end.
>>
>> test2() ->
>>     try exit(2) catch Class:Reason -> {Class,Reason} end.
>>
>> test3() ->
>>     try (a=b) catch Class:Reason -> {Class,Reason} end.
>>
>> test4() ->
>>     try 1/0 catch Class:Reason -> {Class,Reason} end.
>>
>> test5() ->
>>     try foo:bar() catch Class:Reason -> {Class,Reason} end.
>>
>>
>> First compile:
>> tryme.erl:11: Warning: no clause will ever match
>> tryme.erl:14: Warning: this expression will fail with a 'badarith'
>> exception
>>
>> On line 11 there are no try clauses, but catch clauses that will always
>> match, so the warning is a bit strange.
>> And the expression on line 14 is a try, so it will never fail with
>> badarith, possibly return an error tuple lets see:
>>
>> > tryme:test1().
>> {throw,x}
>> > tryme:test2().
>> {exit,2}
>> > tryme:test3().
>> {error,{badmatch,b}}
>> > tryme:test4().
>> {error,badarith}
>> > tryme:test5().
>> {error,undef}
>>
>> This looks a bit more like I would expect.
>>
>> Comments?
>>
>> /Tony
>>
>>
>>
>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
>
> "Installing applications can lead to corruption over time. Applications
> gradually write over each other's libraries, partial upgrades occur, user
> and system errors happen, and minute changes may be unnoticeable and
> difficult to fix"
>
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140917/df49fa57/attachment.htm>