Small poll

[Chris Pressey]

On Thu, 18 Dec 2003 10:29:06 +0100
Bengt Kleberg <Bengt.Kleberg@REDACTED> wrote:

> Chris Pressey wrote:
> > But even if you don't use it, you have to recognize that many
> > programmers do, and for the "let it crash" style to work, code has
> > to be allowed to crash at runtime, even when it "can't be right".
> 
> yes, i am all for letting code crash. i just do not think it is
> usefull to let the compiler produce code for a module that will always
> crash because potentially correct code is written in such a way as to
> produce a runtime error.
> 
> use
> erlang:throw/1
> or
> erlang:exit/1
> if an runtime error is what you want.

You're of course entitled to hold any opinion you wish, but I really
have to say that I disagree, and that I can't quite see your reasoning.

In Erlang as we know it, a + 42 generates an exception.  An exception is
by definition not a show-stopper; it can be caught and acted upon.  But
by changing it into a compile-time error, you're not even giving the
program an *opportunity* to crash.  This runs against the "let it crash"
philosophy in my book.

Also, by forcing the programmer to write throw(blah) to cause an
exception, you're making them *make* it crash, which also runs counter
to "let it crash" - the programmer needn't exert such explicit effort.

To once again attempt to illustrate the difference:

  foo() = (catch bar()).
  bar() ->
    true = some_assertion_which_may_or_may_not_be_constant(),
    stuff().

...versus...

  foo() = (catch bar()).
  bar() ->
    case some_assertion_which_may_or_may_not_be_constant() of
      true -> stuff();
      false -> throw(badarg)
    end.

I'd much rather write (and read) the first version than the second.
Maybe it's just me, but I think it's more concise, more direct, and just
generally clearer.  I also don't think it makes sense for the
compilation itself to succeed or fail based solely on whether
some_assertion_which_may_or_may_not_be_constant() is (detectably)
constant or not.  That's why I'd much rather it be merely a compile-time
warning.

I'm all for getting as much information about possible errors as early
as possible - but I'm not in favour of dramatic shifts in how this
information would affect what is and what is not "legal Erlang".

-Chris