<br><br><div class="gmail_quote">On Tue, Mar 24, 2009 at 2:48 PM, Adam Lindberg <span dir="ltr"><<a href="mailto:adam@erlang-consulting.com">adam@erlang-consulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">----- "Hynek Vychodil" <<a href="mailto:vychodil.hynek@gmail.com">vychodil.hynek@gmail.com</a>> wrote:<br>
> 1/ Exception costs more than checking return value. In most cases it<br>
> will<br>
> not be issues but you can't assume that it will not be. When it<br>
> happen, your<br>
> code is less flexible.<br>
> 2/ Flexibility is throw out when I want code like:<br>
> is_new_email(Email1),<br>
> is_new_email(Email2).<br>
</div><div class="im">> Now I can't distinguish which one Email is wrong without catching<br>
> throw in<br>
> each statement. With my code it is easy:<br>
> {ok, first_one} = {is_new_email(Email1), first_one},<br>
> {ok, second_one} = {is_new_email(Email2), second_one}.<br>
</div><div class="im">> Again, your code is less flexible.<br>
<br>
</div>Well, just throw {email_in_use, Email} then?<br>
<br>
Using tagged tuples just for pattern matching (and really just to make the badmatch error more informative) isn't very readable. It just adds a lot of clutter.<br>
<br>
With the try statement, you CAN have several expression in the same block. You can't have that with a case statement. Unless you accept executing them both to know if either one failed, like in case {a(), b() of {true, true} or something.<br>

<div class="im"><br>
> Throwing exception when it is not necessary is less flexible. I can<br>
> easily<br>
> turn return value to exception but opposite way is harder. Explicit<br>
> throwing<br>
> exception *is* slower and less flexible!<br>
<br>
</div>Performance is rarely an issue in real life code with these kind of constructs. If it is, you probably have bigger problems than changing all your try statements to catch statements.<br>
<br>
It is not harder to change throw to a return value, than a return value to a throw. Either way you're doing it, it is the same amount of code.</blockquote><div><br>code <br><br>ok = is_new_email1(Email).<br><br>doesn't looks like same amount of code<br>
<br>try is_new_email2(Email) catch throw:email_in_use -> email_in_use end.<br><br>First one turns return value to exception, second one  turns exception to return value. Second one seems more code, does not?<br><br>Even code<br>
<br>is_new_email1(Email) -><br>
  case mnesia:dirty_read(email, Email) of<br>
    []    -> ok;<br>
    _ -> email_in_use<br>
  end.<br><br>seems less than <br><br>is_new_email2(Email) -><br>

  case mnesia:dirty_read(email, Email) of<br>

    []    -> ok;<br>

    _ -> throw(email_in_use)<br>

  end.<br>
<br>You did not show even one example where explicit exception throw is more flexible.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Exceptions are used for exceptional things, like for example when a user tries to register with an email already in use. Probably the same user or another user who misspelled, not really that common to be a performance bottleneck.<br>

<br>
It is also nice to use throw since it is a developer intended exception and is very visible when it is not catched. If you get a badmatch somewhere high up in your code then you probably have a bug somewher. If you get an uncatched throw, then you know you haven't implement the necessary code to handle the exception.<br>

<br>
Cheers,<br>
<font color="#888888">Adam<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br><br>Analyze your data in minutes. Share your insights instantly. Thrill your boss.  Be a data hero!<br>Try Good Data now for free: <a href="http://www.gooddata.com">www.gooddata.com</a><br>