Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Custom exception types could be useful #62

bmillwood opened this Issue · 6 comments

3 participants


Ideally, users of the code would never want to read the string inside an exception to find out information about it: that's only useful for showing to humans. So whenever we throw a userError, we're kind of saying "the program has no useful information to give you about what error just happened". I think often this is not the case, and we should either use existing error types more effectively, or create some of our own.


I agree. I've had thought about creating a SocketError type in the past. It might be worth looking at the thoughts the Python people have when they recently redesigned part of the their hierarchy (


Custom exceptions make error handling much messier. Suggest using Either where appropriate.


@singpolyma We're talking about replacing the current exceptions with more specific ones, so they can be caught, not changing the API to return an error code instead.


@tibbe but custom exception types make exception handling harder (cannot just catch IOException / IOError, and do not want to catch SomeException because it encompasses many should-not-catch and asynchronous exceptions).


Possibly it's reasonable to object that you can no longer catch just one exception, but I don't think that's usually what you want to do, anyway - you want to catch a specific error and respond appropriately.

We could always provide a helper function that caught both IO and socket errors and handled them the same way.


@benmachine I try to catch all reasonable exceptions all the time, so that I can handle them in EitherT.

Such a helper function sounds like it might solve the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.