[erlang-questions] The If expression

[Richard O'Keefe]

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
is over
	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>),
	    <good result>

> 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  
> 'case'.

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.

asso