Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a type class for principled error handling #2229

Open
LukaJCB opened this issue Apr 16, 2018 · 4 comments
Open

Add a type class for principled error handling #2229

LukaJCB opened this issue Apr 16, 2018 · 4 comments
Assignees

Comments

@LukaJCB
Copy link
Member

LukaJCB commented Apr 16, 2018

We currently have ApplicativeError and MonadError, but as I argue in this blogpost it has some limitations that I think we can and should overcome. I'd be happy to lead the charge on this if no one else steps up and I'd be even more happy to get some help on naming things :)

@kailuowang
Copy link
Contributor

kailuowang commented Apr 16, 2018

I think this as a transformation between MonadError and Monad, so we might not need to have Monad in the name. With that consideration, the first name that comes to my head is ErrorHandling

@LukaJCB
Copy link
Member Author

LukaJCB commented Apr 16, 2018

I like it! Though I think people might get confused when MonadError defines handleError and ErrorHandling does not. Maybe a different verb, ErrorControl?

@kailuowang
Copy link
Contributor

I love ErrorControl.
As for the encoding, I am curious if the inclusion of instances of MonadError and Monad is necessary since the core laws don't need them, right? Having them might be more convenient at use site, but if the usage is mainly at a middle layer then maybe not? I have any practical experience to evaluate that though.

@LukaJCB
Copy link
Member Author

LukaJCB commented Apr 16, 2018

The laws did need them at some point, but I've revised them a lot so it might be that they no longer do. 😄 I think we need atleast ApplicativeError to get raiseError and formulate the laws, though then we no longer get the ensure counterpart assure. The G[_] part currently only uses pure after removing a discarded law, so that should work :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants