Not learnèd enough in Haskell yet to comment on the primary debate here, but I will say that I am in complete agreement with the author at least emotionally: the existing exceptions “story” with GHC IO is certainly confusing, but also it just seems really bad w/r/t writing reliable code.

Perhaps it’s just because I am a newbie, and I spend my days awaiting enlightenment with open arms, but as it is I would feel 100x more comfortable writing “reliable” (as in, doesn’t unexpectedly terminate) code with Swift — or Java for that matter — than Haskell. And that is after reading absolutely everything I’ve been able to find about Haskell exceptions, trying to understand the whole “no, unchecked exceptions are actually good, you see!” point of view.

Did you read the article? I thought I had been clear enough to avoid this misunderstanding by this point. This is not about the difference between synchronous and asynchronous exceptions, that was previously a misunderstanding caused by bad documentation on my part. The article (and the library) now clearly state the intent: I want to model recoverable errors. That is, things that the program can recover from and do something useful about. safe-exceptions is designed for a different purpose and does not provide this functionality.

Besides the fact that the library is not intended for the use case of sync vs async, additionally it is not possible to have a type that excludes all “synchronous” exceptions anyway, since they can be produced by pure code