[Haskell-cafe] Proper exception handling
Stefan O'Rear
stefanor at cox.net
Sun Feb 10 15:28:01 EST 2008
On Sun, Feb 10, 2008 at 02:49:39PM -0500, Thomas DuBuisson wrote:
> Cafe,
> Fact 1: ghc{,i} does not crash when executing this code.
> Fact 2: I do not want this to crash.
> Question: Is there some theoretical window between the 'catchDyn' exception handling and the recursive call to 'catchThatDamnError' that could result in an unhandled exception? (of type 'DynError', of coarse)
>
> I suppose I am looking for an answer to this question from a language standpoint as well as a compiler pov.
>
> As an aside: I see at least one way to be certain of the safty by wrapping the call to forkIO in 'catchDyn', reforking if an exception is caught, and passing the new ThreadId to throwConstantly via shared mutable state - I'd like to avoid all this if my current example is safe.
>
> Thomas
Asynchronous exceptions are blocked in handlers, so there is no window -
infact all exceptions after the first won't be delivered at all.
However, you could be unlucky enough to throw the first error before the
first catchDyn, so more synchronisation might be needed.
Stefan
>
> > import Control.Exception (catchDyn, throwDynTo)
> > import Control.Concurrent (forkIO, threadDelay)
> > import Control.Monad (forever)
> > import Data.Dynamic
> >
> > main = do
> > tid <- forkIO catchThatDamnError
> > forever $ throwConstantly tid
> >
> > catchThatDamnError = catchDyn start (\DynError -> catchThatDamnError)
> >
> > start = do
> > threadDelay 5000
> > start
> >
> > throwConstantly tid = do
> > throwDynTo tid DynError
> >
> > data DynError = DynError deriving (Eq, Ord, Show, Typeable)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080210/1aa18a5f/attachment.bin
More information about the Haskell-Cafe
mailing list