moving general-purpose functions from httpd_util to stdlib

[Chris Pressey]

Thanks, everybody.

But I have to apologize for that bad example.  The 'error' is a red
herring that clouds the issue.  The question is more about whether it is
wiser, in general, to write "open" or "closed" cases.

A (possibly) better example:

  % "open" case
  case A > B of
    true ->
      41;
    _ ->
      42
  end

  % "closed" case
  case A > B of
    true ->
      41;
    false ->
      42
  end

  % "let-it-crash" style - seems almost like a different problem
  case catch begin
                true = A > B,
                41
             end of
    {'EXIT', Reason} ->
      42;
    Result ->
      Result
  end

-Chris

On Tue, 15 Apr 2003 02:12:39 +0200
"Robert Virding" <robert.virding@REDACTED> wrote:

> ----- Original Message ----- 
> From: "Bengt Kleberg" <eleberg@REDACTED>
> To: <erlang-questions@REDACTED>
> Sent: Monday, April 14, 2003 8:08 AM
> Subject: Re: moving general-purpose functions from httpd_util to
> stdlib
> 
> 
> > 
> > > 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.
> 
> I think I would try to qualify that a little more. It depends on what
> type of failure you mean. I would generally say that bad argument type
> or values should generate an exit so it is quite clear that Chris's
> hex conversion functions should only return the value and exit on
> failure. However, there are many cases where the non-success
> case does not really represent an error and then it should not
> generate an exit but use qualified return values like
> {ok,V}/{error,R}. Maybe the convention to use ok/error was badly
> chosen and we should have used yes/no but I think it would be
> worse to try and have two, or more, "conventions". Better to
> have one and try to explain how it is used.
> 
> This is why most of the original, older libraries at least very rarely
> check arguments types and values but just assume they are
> correct and otherwise exit. As do most bifs. You can't do anything
> sensible if the arguments are all wrong.
> 
> Another example would be file:open. As I envisaged when I wrote
> it was that if the arguments were of the wrong type or had illegal
> values ('creat') then it should exit. However, not being able to
> open the file I didn't really see as an error so it returned qualified
> values to indicate this. What it exactly does now I don't know.
> 
> Not everyone agreed with me.
> 
> Basically there are errors and errors.
> 
> Robert
>