Try/Cond

[Francesco Cesarini]

>
>
>  What - you're nuts
>
It is pretty well known ;-)

>>With the introduction of OTP in 1996, I have never seen anyone use exit 
>>in their code. The few catches and throws I came across were easily 
>>rewritten into a more purely functional style.
>>    
>>
>
>  My code has loads of exits.
>
In other threads, it was pretty much agreed that, even if pretty, your 
code differed from the norm. :-p It would be a consultant's dream to 
have 40 programmers, each terminating their behaviors with different 
reasons, starting to make strange checks and handling error cases that 
will never occur.

>  The golden rule is "let it crash" - quite often code will crash
>with a less-than-helpful (TM) diagnostic. Here I always write
>
>	exit(<<some helpful diagnostic>>)
>
Of course, let it crash. But instead of exits, I prefer to just handle 
positive cases. If you know an element will be in a list, {value, 
Element} = lists:keysearch/3 should suffice. Others, depending on their 
background, would have code handling lots of estranged weird cases that 
should never occur, for the sake of 'Just in case the data is 
corrupted'. Data shouldn't be, so don't worry about it. (The best 
examples are from a project where the bonus was based on the number of 
bugs in the code, and people interpreted a bug as having their process 
crash, even if it was not their fault).

>  There is no way of getting a non-local return from a function if you
>do not use catch and throw.
>
Of course, as was mentioned yesterday, the main usage is when handling 
unreliable input in deeply nested functions, e.g. parsing. Other than 
that, it makes the code very hard to understand and debug. That, because 
the errors occur when they are used as a replacement to gotos, used 
across modules, and not with extreme care.

>  Pleeeese teach you students the correct way to use catch/throw/exit -
>this will lead to much cleaner code than if they try religiously to avoid their use.
>
I do (After all, you were the one who brain washed me into writing 
pretty understandable code :-p). Based on design guidelines, experience, 
and their individual ability to grasp what I am explaining, this will 
have to vary the depth in which we cover the subjects.

Got to go! The men in the green shirts are knocking on the door.

Regards,
Francesco
--
http://www.erlang-consulting.com