moving general-purpose functions from httpd_util to stdlib

[Chris Pressey]

On Sun, 13 Apr 2003 21:02:50 +0200
"Robert Virding" <robert.virding@REDACTED> wrote:

> Yes, add these!
> 
> Robert

I still have some reservations on my final patch.

- hex could be done equally well with io:format or
erlang:integer_to_list.  If one of these is settled on as officially,
I'll happily redo my patch to use it instead of math:base.

- httpd_util:hexlist_to_integer and integer_to_hexlist return
not-very-helpful atoms ('error', 'empty' or 'not_a_num') in the case of
an error.  In the interests of backwards-compatibility, I made math:base
return the same atoms.  However, when you consider that:
  - these error returns aren't documented in the httpd_util manpage
  - other httpd_* modules don't seem to check explicitly for them
...one wonders whether it would be wiser to improve the error handling,
at least to the point where they return {error, Reason} like so many
other functions do.

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

You can write a caller of foo either like this:

  case foo() of
    I when is_integer(I) ->
      bar(I);
    error ->
      {error, foo_failed}
  end

or like this:

  case foo() of
    I when is_integer(I) ->
      bar(I);
    _ ->
      {error, foo_didnt_return_an_integer}
  end

The first seems to be more in tune with "write for the correct case,
otherwise just let it crash."  You know the range of foo(), and you
write the case to map exactly to that range.

The second seems to be more in tune with "defensive programming," at
least one definition of it that I've seen mentioned.  You're assuming
that the range of foo() might be expanded in the future, and you don't
want to have to change your foo-caller code.  (and/or you didn't read
the documentation for foo() too closely and you only know that it can
return 'at least' an integer)

The question is - which is wiser?  The first is clearer (easier to
follow by reading,) but the second is less fragile (more resistant to
interface evolution.)  Presently, I'm quite undecided, and would be
interested in hearing other Erlang programmers' thoughts on this.

Anyway - in the future, I won't clutter this list with patches, I'll
send them to erlang-patches@ only.

-Chris