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