[Haskell-cafe] Exception handling when using STUArray

[Sterling Clover]

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 at kf8nh.com
> system administrator [openafs,heimdal,too many hats]  
> allbery at ece.cmu.edu
> electrical and computer engineering, carnegie mellon university     
> KF8NH
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe