Small poll

[Peter-Henry Mander]

On the "let it crash" vein of the topic, I'm writing a SIP message parser. I ended up writing functions and code that only match positively with lexemes, letting the parser "crash" on mismatches, and catching to retry with alternative lexemes where multiple matches may occur. It makes the lexer *much* easier to read and debug!

In the end the parser exclusively uses only pattern matching and function clauses. No "if" or "case" or any other syntactic sugar. And it reads very clearly! (well, for me at least!)

Adding clauses containing exit, throw or returning {error,ErrCode} just adds clutter with no advantage whatsoever.

Pete.

On Thu, 18 Dec 2003 12:03:58 -0800
Chris Pressey <cpressey@REDACTED> wrote:

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


-- 
"The Tao of Programming
 flows far away 
 and returns 
 on the wind of morning."