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.
I don’t recommend using this library, author doesn’t understand asynchronous and synchronous exceptions in GHC. Others tried to intervene to get it fixed and they chose to be difficult.
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
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
IOis 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.
Especially for a language and ecosystem so otherwise obsessed with type-level safety of every kind… I just don’t get it
Why does your site ask for permission to send me notifications when I visit it?
There’s a weird JS/chat widget.
The “chat me” button in the bottom right has the ability to notify. I may look into a way to disable that.
I don’t recommend using this library, author doesn’t understand asynchronous and synchronous exceptions in GHC. Others tried to intervene to get it fixed and they chose to be difficult.
I usually use https://hackage.haskell.org/package/safe-exceptions or https://hackage.haskell.org/package/unliftio-0.2.7.0/docs/UnliftIO-Exception.html
You can check who uses a library by using this website: https://packdeps.haskellers.com/reverse/unexceptionalio
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-exceptionsis 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