Re: Final bikeshedding call: Fixing Control.Exception.bracket

On 2014-11-13 23:42, Gregory Collins wrote:

On Thu, Nov 13, 2014 at 10:59 AM, Bardur Arantsson 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.

Rather, my > experience tells me that the change is super scary (any similar change in > how a core error-handling primitive behaves in the

Yes, you are! Oh, wait, sorry, this isn't a Monty Python sketch... :) 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,