[erlang-questions] The If expression
Fri May 28 07:16:03 CEST 2010
On May 28, 2010, at 1:20 PM, Henning Diedrich wrote:
> I think I found my one-armed-if at long last!
> Shame on everybody standing by who knew it all along and chuckled
> with glee:
> Index /= null orelse throw(index_null).
Sounds like you've rediscovered Perl's
<condition> || die <message>;
idiom. It's generally recommended in Erlang to use 'error'
for errors, not 'throw'.
It's not really clear to me how much of an improvement this
if <guard> -> ok end
> But whenever exceptions come into play, the return value argument
> can become mute I found, in FP.
I think you mean "moot" (mOOt, subject to debate)
not "mute" (mEWt, silent).
> As suggested by the fact that the result of the after-body of try-
> catch-after constructs are discarded as well. Currently I'd argue
> that in an analogous way the second arm of 'case' or 'if' is not
> necessarily-necessary when the only arm that matters is ending on
> throw/erlang:error/exit. If I wisen up, I promise I'll retract.
I don't think anybody was arguing against
if <all is well> -> <good result> end
when the *intention* is that the process should crash/raise an exception
on failure. Indeed, no second arm is required in this case. But then,
the programmer's intentions are much more clearly stated if you write
?define(ASSERT(Guard), if Guard -> ok end).
?ASSERT(<all is well>),
> But especially when I need to throw an error /from/ a place 'higher
> up' in the call stack to put more information with it, I couldn't
> always find a sensible way to use the second arm of and 'if' or
Give an example.
With exception handling there are at least two separate issues:
- unwind-protect; ensuring that actions are properly undone when
an exception occurs
- recovery and resumption.
The big issue about exception handling is that the exception has
to be *recognised*, *understood*, and *recovered from*.
One would have to see the context, but things like 'index_null' have
a nasty habit of referring to data other than stuff the original
caller passed in, and might not even be able to name.
It really is important to see a real example here.
More information about the erlang-questions