<div dir="ltr">On Wed, Sep 17, 2014 at 1:50 PM, Tony Rogvall <span dir="ltr"><<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><div>On 17 sep 2014, at 00:46, Daniel Luna <<a href="mailto:daniel@lunas.se" target="_blank">daniel@lunas.se</a>> wrote:</div></span></div><div><span class=""><blockquote type="cite"><p dir="ltr">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.</p></blockquote></span><div>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 </div><div>but not even smart enough to see that it is caught?</div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>   /Richard<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><br><blockquote type="cite"><p dir="ltr">Regards,</p><p dir="ltr">Daniel</p>
<div class="gmail_quote">On Sep 16, 2014 6:18 PM, "Tony Rogvall" <<a href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
Not sure how this is supposed to be, given that there is a shell function called catch_exception/1.<br>
<br>
Running in 17.1 (approx)<br>
<br>
> try throw(x) catch Class:Reason -> {Class,Reason} end.<br>
{throw,x}<br>
<br>
> try exit(2) catch Class:Reason -> {Class,Reason} end.<br>
* exception exit: 2<br>
<br>
> try foo:bar() catch Class:Reason -> {Class,Reason} end.<br>
* exception error: undefined function erl_eval:expr/3<br>
<br>
> try 1/0 catch Class:Reason -> {Class,Reason} end.<br>
* exception error: an error occurred when evaluating an arithmetic expression<br>
<br>
> try (a=b) catch Class:Reason -> {Class,Reason} end.<br>
* exception error: no match of right hand side value b<br>
<br>
Putting the above try expression in a module:<br>
<br>
-module(tryme).<br>
-compile(export_all).<br>
<br>
test1() -><br>
    try throw(x) catch Class:Reason -> {Class,Reason} end.<br>
<br>
test2() -><br>
    try exit(2) catch Class:Reason -> {Class,Reason} end.<br>
<br>
test3() -><br>
    try (a=b) catch Class:Reason -> {Class,Reason} end.<br>
<br>
test4() -><br>
    try 1/0 catch Class:Reason -> {Class,Reason} end.<br>
<br>
test5() -><br>
    try foo:bar() catch Class:Reason -> {Class,Reason} end.<br>
<br>
<br>
First compile:<br>
tryme.erl:11: Warning: no clause will ever match<br>
tryme.erl:14: Warning: this expression will fail with a 'badarith' exception<br>
<br>
On line 11 there are no try clauses, but catch clauses that will always match, so the warning is a bit strange.<br>
And the expression on line 14 is a try, so it will never fail with badarith, possibly return an error tuple lets see:<br>
<br>
> tryme:test1().<br>
{throw,x}<br>
> tryme:test2().<br>
{exit,2}<br>
> tryme:test3().<br>
{error,{badmatch,b}}<br>
> tryme:test4().<br>
{error,badarith}<br>
> tryme:test5().<br>
{error,undef}<br>
<br>
This looks a bit more like I would expect.<br>
<br>
Comments?<br>
<br>
/Tony<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org" target="_blank">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
</blockquote></div>
</blockquote></div><br></div></div><div>
<span style="border-collapse:separate;border-spacing:0px"><div><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px">"Installing applications can lead to corruption over time. </span><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px">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"</span></div><div><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px"><br></span></div></span><br>
</div>
<br></div><br>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br></div></div>