[erlang-questions] The If expression

[Henning Diedrich]

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).


*love it* *beautiful* *ouch* *ey! stop that!*

I am still trying hard to avoid the need for a one armed if as per the 
reasons brought up in this thread.

Many times I succeed and the extra effort pays off in a yet better 
understanding of the FP ways.

However, whenever the desire is for more informative error messages --- 
over 'just let it crash' --- anything else clutters the code and 
one-armed ifs *are* the right thing to use there because I don't care 
for all the other cases. In such cases I am not interested in what value 
may be returned because I will break away anyway.

And better error messages are a legitimate constraint sometimes. I 
understand it's not in Erlang's heritage in some way.

Message passing and IO are other areas where side effects are the focus, 
not return values. And where therefore one-armed ifs could be a honest 
thing.

 From all the help, which I want to say *thank you* for, the following 
had been the strongest advice that stuck with me in its simplicity and 
fair abstraction:

Robert Virding wrote:
> ... however you choose to use 'if', or any other
> construction for that matter, Erlang is a functional language and
> everything returns, and must return, a value. 
Thanks, Robert, this reminder helped to get into the right thinking 
often times!
> So even if 'if' didn't
> need to have an explicit default or else case then it would still have
> to return a value. We would never be able agree on a default value
> anyway. :-) 'nil' is not a good value here as it has no inherent
> meaning in Erlang as it does in Lisp.
>   
It probably held true 80% of the times when I ran into a subjective (<- 
qualifier inserted for Rich!) need of a one-armed-if.

But whenever exceptions come into play, the return value argument can 
become mute I found, in FP. 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 did find very many occasions where instead of a 'case', the correct 
pattern matching in the function head made all the difference, or a 
'case' structure could with some deliberation be rewritten to have a 
sensical second arm.

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'. (Re 
throwing from higher up: e.g. a list may have been consumed in its 
entirety 'lower down' when I realize a dead end is hit. And so I can't 
show it in the error message if it's thrown from there. Unless I add a 
parameter.)

Thank you again for all your thoughts, they are very much appreciated.

Henning