Proposal: Extensible exceptions

Brandon S. Allbery KF8NH allbery at ece.cmu.edu
Fri Jul 18 13:17:20 EDT 2008


On Jul 18, 2008, at 12:04 , Duncan Coutts wrote:
> On Fri, 2008-07-18 at 11:19 -0400, Brandon S. Allbery KF8NH wrote:
>> I'm going to ask a possibly silly question:  has anyone thought about
>> this vis-a-vis Simon's proposal of a new signals API?  It's not that
>> unusual for signals (usually SIGUSR1/SIGUSR2, often SIGINT, SIGHUP,
>> sometimes SIGABRT, SIGQUIT) to be used as asynchronous triggers ---
>> which might be best represented in the "Haskell world" as special
>> exceptions.  Likewise, it often makes sense to treat SIGPIPE, SIGHUP,
>> SIGINT as exceptions instead of signals.
>
> SIGINT will be an exception in ghc-6.10. It will throw an async
> exception to the main thread. We're just trying to think of the  
> details
> though, eg how to programs like ghci ignore ^C and can it be done in a
> portable way.
>
> SIGPIPE can be ignored because we get a sync exception when we write  
> to
> a pipe with no reader.

I think I was more getting at (a) reserving an exception "class" for  
remapped signals, and (b) optionally providing a convenience function  
to install a signal handler for a given signal that maps it to the  
equivalent exception.

This should be possible as a separate library, if the extensible  
exceptions are designed right...


-- 
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




More information about the Libraries mailing list