Proposal: Extensible exceptions
duncan.coutts at worc.ox.ac.uk
Fri Jul 18 19:26:27 EDT 2008
On Fri, 2008-07-18 at 13:17 -0400, Brandon S. Allbery KF8NH wrote:
> 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,
What do you mean exactly?
> and (b) optionally providing a convenience function to install a
> signal handler for a given signal that maps it to the equivalent
That's pretty trivial, one line of code:
addSignalHandler sigWHATEVER $ \_ -> throwTo threadid exception
I'm not sure it's worth adding anything special.
More information about the Libraries