There are too many error handling conventions used in library code!

[Simon Peyton-Jones]

You may find these papers relevant, especially the first.  (Yes, you can catch and recover from head []!)

http://research.microsoft.com/en-us/um/people/simonpj/papers/imprecise-exn.htm

http://research.microsoft.com/en-us/um/people/simonpj/papers/asynch-exns.htm

Simon

|  -----Original Message-----
|  From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] On
|  Behalf Of Jack Waugh
|  Sent: 12 August 2011 20:35
|  To: libraries at haskell.org
|  Subject: Re: There are too many error handling conventions used in library code!
|  
|  In re
|  http://thread.gmane.org/gmane.comp.lang.haskell.libraries/6382
|  
|  I read this thread (as I found it populated on 2011-08-12)
|  with interest even though I have not written three lines
|  of Haskell.
|  
|  I am trying to invent a programming language with
|  referential transparency and I am thinking about what
|  construct(s) it should provide to catch errors.  Catching
|  errors is necessary because I want the language to be
|  suitable for building systems that run code by various
|  contributors without trusting the integrity of the system
|  as a whole to the contributions.  Errors should be caught
|  and reported to the responsible programmers.
|  
|  Let "RT" stand for referential transparency or
|  referentially transparent as grammatically appropriate in
|  each instance.
|  
|  I wanted to learn from the experience with Haskell because
|  Haskell is one of the few pure functional programming
|  languages in use (I'm not sure about the ML family, and I'm
|  pretty sure that Erlang and the E language are not pure).
|  At least with Haskell I know for sure it is pure, so
|  I think that the community around Haskell has advanced
|  understanding of how to go far within a purely RT world.
|  
|  So I start poking around to figure out how errors are
|  caught, and the upshot, from this thread, seems to be,
|  that errors cannot be caught in Haskell.  I see you all
|  talking about how libraries' APIs should incorporate
|  error reporting, but these seem like really exceptions
|  rather than errors, in that you, the library prorammers,
|  have to plan to detect them and you are just looking
|  for a non-noisy way to pass them back through the API,
|  since these "errors" represent cases that for good reason
|  shouldn't dominate the body of your code (all of us would
|  prefer, and with excellent reason, that the bulk of our
|  code reflects programming for the normal and happy cases).
|  Maybe these error cases you're discussing, some of them,
|  reflect an error on the part of the programmer of the
|  _client_ code _calling_ the library, and that's why you
|  want to use the term "error".  But a true programming error
|  (for example, in the library code) might not be possible
|  to anticipate and program around; after all, it's an error.
|  A programming mistake.
|  
|  For example, what happens if we try to take the head of
|  an empty list?  Everything dies, right?  Haskell won't
|  catch that, right?
|  
|  So, here's what I'm thinking for my language.  Every data
|  type (I don't think I'll need Unit) will have implicitly
|  some error indications as possible values.
|   So for example, if an Integer is expected, we might get
|   an integer, such as 3
|  for example, but we could instead receive an error
|  indication.  It should be possible to test explicitly
|  for an error indication, and on finding one, it should be
|  possible to test it for membership in various interesting
|  classes of errors (including programmer-defined ones) and
|  it should be possible to dig into the error indication and
|  extract a brief explanation in natural language of what
|  went wrong.  I'm thinking location information such as
|  source file name (or something like that) and line number
|  could fit in there as well.
|  
|  Functions that are not designed for the explicit purpose of
|  looking for error cases, for example `+`, would propagate
|  errors along to their results if such were found in one or
|  more essential inputs (False && error could return False
|  rather than the error).
|  
|  Now if it looks as though I'm just reinventing
|  something that a monad can do elegantly, I'm not sure.
|  The monadic examples I have been seeing all seem to
|  require the use of the bind function to glue together
|  the function applications that could encounter an error.
|  A reader of the code can't tell that the order of the
|  binds doesn't matter.  It looks like I/O code, where the
|  order definitely does matter.  But if I want to return for
|  example a/b + c/d, and either division could accidentally
|  attempt to divide by zero, I don't want to specify which
|  division comes "first" in some chain of binds; that's
|  overspecification, isn't it?  Because the result does
|  not depend on any ordering of the addends.  Addition is
|  commutative, and it remains commutative if we extend the
|  domains to include error indications.  Error some_specs
|  + 3 = Error some_specs; 3 + Error some_specs = Error
|  some_specs; still commutative.
|  
|  If I adopt this scheme, have I learned everything I can
|  about error catching from Haskell and incorporated that
|  learning into my design?
|  
|  I apologize for posting off topic in your thread, but
|  this is a branching topic closely related to your topic
|  and if I can get the advice of people who are experienced
|  in pure functional programming and who have thought about
|  the problems of error reporting, I might be able to avoid
|  making some really stupid design mistake.
|  
|  I suggest the subject "Learning from Haskell -- Catching
|  Errors" as the subject for any followups to this message.
|  
|  Thanks loads for any response.  And if you think my idea
|  is crackpot, please don't hold back on your opinion.
|  I am trying to make a useful contribution, and if I am
|  barking up the wrong tree, that purpose will not be served.
|  Please feel free to tell me I should read one thing or
|  another that my question indicates I have missed, before
|  trying to design a new RT programming language.
|  
|  Again, my question is "If I adopt this scheme, have I
|  learned everything I can about error catching from Haskell
|  and incorporated that learning into my design?"
|  
|  Jack Waugh http://jackwaugh.com/
|  
|  
|  
|  _______________________________________________
|  Libraries mailing list
|  Libraries at haskell.org
|  http://www.haskell.org/mailman/listinfo/libraries