moving general-purpose functions from httpd_util to stdlib

Ulf Wiger etxuwig@REDACTED
Mon Apr 14 12:25:47 CEST 2003


On Mon, 14 Apr 2003, Bengt Kleberg wrote:

>> Date: Mon, 14 Apr 2003 00:01:55 -0500
>> From: Chris Pressey <cpressey@REDACTED>
>...deleted
>
>> This brings up one of those burning questions of our times - that is,
>> what exactly "defensive programming" means in the context of Erlang.
>>
>> Say you have a function foo() that can return either an integer or the
>> atom 'error'.
>
>an alternative to this problem is described by Richard Carlsson:
>
>		- A function should *not* return wrapped values like
>		  {ok,Value}/{error,Reason} to indicate success or
>		  failure. The assumed behaviour should be success,
>		  and failures should be signalled by exceptions,
>		  as described below.

This is the behaviour I much prefer.

I think one should always try to think about what a user can
reasonably do if the requested operation doesn't succeed. If
the normal case is to exit, then I think it's best to have
the original function exit right away. If the odd caller
does not want to exit, there's always catch.

I've seen tons of code where the caller checks the return
value in the following manner:

case foo(X,Y,Z) of
   {ok, Result} ->
      ...;
   {error, Reason} ->
      {error, Reason}
end.

If this type of pattern is scattered all over in your
programs, then you'd be much better off writing functions
that either succeed or fail distinctly.

One of my favourite examples has been timer:send_after/3,
which returns {ok, TRef} | {error, Reason}. How many times
when you've ordered a timer has there been any reasonable
alternative action in the event that a timer weren't
available?


/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes




More information about the erlang-questions mailing list