[Haskell-cafe] ANN: asynchronous-exceptions

[João Cristóvão]

Just to let you know, the enclosed-exceptions is now at Hackage, allowing
you to use the functions previously discussed without adding the heavier
dependency on Classy Prelude.

http://hackage.haskell.org/package/enclosed-exceptions


Cheers,
Joao


2014-02-06 12:35 GMT+00:00 Michael Snoyman <michael at snoyman.com>:

> I like the idea of renaming the module to reflect this concept (I'm fine
> with either Inner or Enclosed), but leaving the function names themselves
> as-is.
>
>
> On Thu, Feb 6, 2014 at 2:12 PM, João Cristóvão <jmacristovao at gmail.com>wrote:
>
>> Thanks Roman and Michael for the latest clarifications:
>>
>> I had indeed forgot the case where a thread runned in catchAny spawn
>> child threads that kill their parent.
>>
>> > But given how overloaded the term is, I'd be in favor of coming up with
>> a new term to represent what these catch functions are intended to do.
>>
>> The word currently in my head is 'inner', although Roman's suggestion
>> of 'enclosed' looks fine too. Internal is also correct, but as it is
>> regularly used to denote a package internal functions, it may lead to
>> confusion.
>>
>> What these functions (classy prelude/my library spin-off) do is run a
>> computation, isolating it from the calling thread (through async) and
>> catching all inner exceptions (of either synchronous or asynchronous
>> type, raised by either throwIO or throwTo instructions _present
>> somewhere inside that computation_, or by the RTS but once again
>> affecting only that computation, not the calling one.
>>
>> The calling one is thus 'free' to receive asynchronous exceptions in
>> the meantime (the execution of the inner computation).
>>
>> Thus, I propose either:
>>
>> Control.Exception.Inner / Control.Exception.Enclosed
>>
>> And/or, possibly also rename the functions to something like:
>>
>> catchAnyInner / catchAnyEnclosed
>>
>> Although I do not like this last option so much, the function name
>> gets too long, but that's a personal preference.
>>
>>
>> What do you think?
>> João
>>
>> 2014-02-06 Michael Snoyman <michael at snoyman.com>:
>> >
>> >
>> >
>> > On Thu, Feb 6, 2014 at 8:17 AM, Roman Cheplyaka <roma at ro-che.info>
>> wrote:
>> >>
>> >> > Am I getting this right?
>> >>
>> >> Not quite.
>> >>
>> >> The enclosed computation may get asynchronous exceptions whatever
>> >> definition of 'asynchronous' you use -- the exact one (by throw method)
>> >> or the approximate one (by type).
>> >>
>> >> Just a couple of examples:
>> >>
>> >> * The thread may catch an async exception from the RTS (such as
>> >>   BlockedIndefinitelyOnMVar or StackOverflow)
>> >> * The thread may spawn other threads, passing its pid to them, and one
>> >>   of its children may eventually kill it
>> >>
>> >> So I'd say this method allows to catch any exceptions "related" to
>> >> the computation, synchronous or asynchronous. It is this "relatedness"
>> >> that is enforced by running it in a separate thread.
>> >>
>> >> Roman
>> >>
>> >
>> > I definitely think this is important to get our terminology right. A
>> lot of
>> > the scariness of async exceptions likely spawns from the fact that we
>> use
>> > the same term to refer to a number of very different cases. Let me give
>> a
>> > crack at breaking down exceptions:
>> >
>> > * An exception with a synchronous type (e.g., IOException) thrown via
>> > throwIO. This is the most synchronous of synchronous exceptions.
>> > * An exception with an asynchronous type (e.g., UserInterrupt) thrown
>> via
>> > throwIO. There's legitimate room for debate as to what we should call
>> this.
>> > For my purposes, I'd want to call it a synchronous exception.
>> > * An exception with a synchronous type thrown via throwTo. Similar to
>> > previous bullet, but I'd consider this asynchronous.
>> > * An exception with an asynchronous type thrown via throwTo. This is
>> solidly
>> > an asynchronous exception.
>> >
>> > Then we have some more interesting questions:
>> >
>> > * What *is* an asynchronous type? By including
>> BlockedIndefinitelyOnMVar, it
>> > seems like you're defining it to include any exception generated by the
>> RTS.
>> > However, I'd consider it a synchronous exception: it is generated in
>> direct
>> > consequence of performing an IO action. It just happens to be generated
>> by
>> > the RTS instead of via some library talking to the filesystem.
>> > * What happens if an async exception is caught and then rethrown? Has it
>> > transformed itself into a synchronous exception? That's a tricky
>> question,
>> > and likely depends on the exact manner in which is was caught.
>> > * What happens if a function utilizes some form of asynchronous
>> exception
>> > mechanism to affect its behavior? The prime example of this is
>> `timeout`, or
>> > better, the `asyncTimeout` function I displayed above. Internally to
>> that
>> > function, I think that's an async exception. However, for a *caller* of
>> that
>> > function, the behavior is actually synchronous: there was no
>> notification
>> > from the outside world changing the behavior of this function, it
>> simply has
>> > the possibility to terminate by throwing a Timeout, the same way a
>> function
>> > may terminate by throwing an IOException.
>> >
>> > That last bullet is crucial to the question of whether classy-prelude's
>> and
>> > João's catching functions are asynchronous or not. But given how
>> overloaded
>> > the term is, I'd be in favor of coming up with a new term to represent
>> what
>> > these catch functions are intended to do.
>> >
>> > Michael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140213/a7244624/attachment.html>