sends don't block, right?

[Vance Shipley]

On Wed, Feb 25, 2004 at 09:25:20AM -0500, Shawn Pearce wrote:
}  
}  ... I usually reply back to the caller in a gen_server when the 
}  call is invalid/unsupported.  This way the caller gets 
}  {error, {badcall, Call}} rather than a server }  crashing.  I 
}  mean, what if a programmer does something stupid in a client


I think this is right.  The philosphy of crashing on programming
errors is a good one however one needs to think about who the 
programmer is when building APIs.  The intent of providing an
API is that the client programmer doesn't have to understand
anything other than the API.  He doesn't want to have to debug
the service he is using therefore a crash report isn't useful
to him.  

I consider API interfaces to be slightly unreliable so do some 
amount of error checking on them.  I like to do things like:

foo(Integer) when is_integer(Integer) ->
	1 + Integer.

Which follows the let it crash and make it crash early philosophy.
This causes the right sort of report:

1> t:foo(a).

=ERROR REPORT==== 25-Feb-2004::13:27:24 ===
Error in process <0.26.0> with exit value: {function_clause,[{t,foo,[a]},{erl_eval,do_apply,5},{shell,eval_loop,2}]}

** exited: {function_clause,[{t,foo,[a]},
                             {erl_eval,do_apply,5},
                             {shell,eval_loop,2}]} **


This tells the client programmer what he needs to know; that there 
is no matching function clause for foo(a).  Without the guard we get:

=ERROR REPORT==== 25-Feb-2004::13:26:54 ===
Error in process <0.24.0> with exit value: {badarith,[{t,foo,1},{shell,eval_loop,2}]}

** exited: {badarith,[{t,foo,1},{shell,eval_loop,2}]} **


The client programmer scratches his head wondering why he's doing
arithmetic.  This exposes the internals of the service unecessarily.


	-Vance