Final bikeshedding call: Fixing Control.Exception.bracket

[Gregory Collins]

On Thu, Nov 13, 2014 at 10:59 AM, Bardur Arantsson <spam at scientician.net>
wrote:

> This sounds like a castle built on sand. One would hope that it's common
> knowledge to *not* attempt to do anything too ambitious in exception
> handlers -- and that even applies in languages *without* async
> exceptions! You log it or perhaps ship an event description to a
> different thread which can report the event, but you should definitely
> not be attempting network traffic in an exception handler.
>
> Is this something you've actually seen in the wild or...?
>

Yes, for other languages. Unfortunately I can't give you more detail than
that.

And what, exactly, is it about exception handlers in Haskell that makes
doing network calls from them a bad idea? I'm seeing a lot of assertions in
this thread that seem rooted in opinion rather than facts. "People
shouldn't do that!", you're arguing, before checking whether or not people
actually do rely on being able to do it.


>> Merijn pointed out that either a cleanup is not interruptible, in which
> > case uninterruptibleMask doesn't change the semantics, or it is
> > interruptible, in which case that's almost certainly a bug.
> >
> > Data please :-). The fact is that currently it is possible to use bracket
> > for control flows that will be unsafe after the proposed change.
>
> "Possible" does not mean "likely", so I'm going to ask for *your* data :).
>

The burden of proof has to be on those who propose to change the existing
documented semantics. Am I being crazy or overcautious to want to insist on
that? I don't think so.


As others have already stated, the work required to do an audit of all
> code using "bracket" is disproportionate to the risk of this change. (Or
> at least the risk that is perceived by the proponents of the change.)
>

Then we disagree on how potentially risky this change is. I've heard
assertions like this before made many, many times right before some
harmless-looking change causes massive breakage. I'll hope you understand
if I'm not immediately convinced :).

I'm not arguing the contra side here just to be obstinate. Rather, my
experience tells me that the change is super scary (any similar change in
how a core error-handling primitive behaves in the presence of concurrency
would be), and that changes to routines like this one need to be done
extremely carefully. If this change does break code, it is likely to do it
in a way that is difficult to isolate and debug.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/b13cf153/attachment.html>