Final bikeshedding call: Fixing Control.Exception.bracket

[Bardur Arantsson]

On 2014-11-13 23:42, Gregory Collins wrote:
> 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.

I wasn't just talking about Haskell. Doing *anything* remotely
interesting in exception handlers in *any* language is a bad idea --
almost without exception (pun!). There's a reason that some of the most
reliable software in the world (in terms of uptime) is written in a
language predicated on the idea of "fail fast (and restart)".

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

You're being overcautious. :)

> 
> 
> 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 think that's the fundamental disagreement, but I don't think it's
going to be solved by debate, so let's just vote and get it over with :)

As as been pointed out repeatedly, code which breaks under this proposal
was already broken or (at the very least) hopelessly optimistic in what
could be achieved in an exception handler.

> I'm not arguing the contra side here just to be obstinate.

Yes, you are! Oh, wait, sorry, this isn't a Monty Python sketch... :)

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

Would you feel better if a new "goodBracket" were introduced and
"bracket" were deprecated and later removed (in GHC 7.12.x or whatever)?

That might at least serve as a compile-time guard against code that
wasn't actively thought about... but than I suspect the end result would
be *exactly* the same as option #2, namely that people would just change
"bracket" -> "goodBracket" without thinking. So we'd be in exactly the
same situation except with arbitrary compile-breakage.

Regards,