[Haskell-cafe] Re: Re: Debugging partial functions by the rules
benjamin.franksen at bessy.de
Wed Nov 15 16:42:26 EST 2006
John Hughes wrote:
>> From: Robert Dockins <robdockins at fastmail.fm>
>> It seems to me that every possible use of a partial function has some
>> (possibly imagined) program invariant that prevents it from failing.
>> Otherwise it is downright wrong. 'head', 'fromJust' and friends
>> don't do anything to put that invariant in the program text.
> Well, not really. For example, I often write programs with command line
> arguments, that contain code of the form
> do ...
> [a,b] <- getArgs
> Of course the pattern match is partial, but if it fails, then the standard
> error message is good enough.
> This applies to "throw away" code, of course, and if I decide to keep the
> code then I sooner or later extend it to fix the partiality and give a
> more sensible error message. But it's still an advantage to be ABLE to
> write the more concise, but cruder version initially.
> This isn't a trivial point. We know that error handling code is a major
> part of software cost--it can even dominate the cost of the "correct case"
> code (by a large factor). Erlang's "program for the correct case"
> strategy, coupled with good fault tolerance mechanisms, is one reason for
> its commercial success--the cost of including error handling code
> *everywhere* is avoided. But this means accepting that code *may* very
> well fail--the failure is just going to be handled somewhere else.
> Haskell (or at least GHC) has good exception handling mechanisms too. We
> should be prepared to use them, and "let it fail" when things go wrong.
> The savings of doing so are too large to ignore.
But note that Erlang will give you a stack trace for unhandled exceptions
which Haskell (currently?) doesn't/can't.
Also, I remember an Erlang expert (Ulf Wiger?) stating recently
that 'catching and re-throwing expections in most cases tends to hide
program errors rather than avoid them' (quoted non-verbatim from memory, I
can't recall the name of the paper).
Lastly, Erlang's "program for the correct case" is not meant for things like
input of data from sources outside the program's control, but only applies
to not-checking for program internal invariants. I would be very surprised
if there were Erlang experts encouraging "throwaway" code such as your
More information about the Haskell-Cafe