On the other hand, there are lots of issues that can be worked on here, foax! While tools like the one is ndm is working on seem to offer a way forward, at the moment, there's no standard way that I know of besides "inspection" to determine if code might throw an exception, and this is particularly the case with the dreaded lazy IO of prelude functions. And as per a recent discussion on libraries, it's still a royal pain to catch IO exceptions in monads with an IO base. And then, of course, there's the issue of exceptions in ST or STM which have similar issues. All this could be solved if we standardized on some version of gcatch over MonadBase or a variant. The machinery just hasn't been fully written yet, although Control.Monad.Error is, sort of, a start. And of course, using head or any other partial functions in production code without a great deal of care is a really *bad idea*, but the prelude sort of locks us into having them at least. Tutorials and examples might be better served emphasizing why these things are dangerous, and common idioms for avoiding them... Regards, sclv On Mar 9, 2008, at 3:09 AM, Brandon S. Allbery KF8NH wrote:
On Mar 9, 2008, at 1:54 , Don Stewart wrote:
donn:
This seems to me one of the disappointments of Haskell - not just a detail that was handled in an awkward way, but a fundamental flaw. I'm not talking about ArrayException, whatever that is, but the notion that errors encountered in functional code mustn't be handled as exceptions.
I don't understand this complaint -- you can handle all these with Control.Exception.
xmonad catches all these things for example, in user code, to prevent poorly written modules throwing a pattern match exception, or calling 'error' and making the window manager unstable.
Handling exceptions generated from pure code is just another part of making systems more robust -- and of course you can do it in Haskell.
I'm unsure what the complaint here is as well.
That exceptions must be handled in IO: an exception is, by definition, an unexpected condition. These simply can not exist in the deterministic paradigm of pure code, therefore you must be in IO (home of all things nondeterministic) to catch them.
That it is preferred to handle known cases without using exceptions: staying completely pure is cleaner, and gives you more control over what goes on. And enables swapping in different mechanisms to react to failure; note how using the Monad instances of Maybe, Either, or [] allows you to decide how to handle failure (and [] allows you to support multiple possible results as well, while Maybe and Either will stop processing at the first.
Basically, the Haskell way is to make as much as possible pure and minimize the intrusion of IO. Exceptions necessarily complicate this, so are when possible avoided in favor of pure alternatives, which are considered better style --- but they are available in IO if needed.
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe