Repository navigation
Custom exception types could be useful #62
Description
Activity
I agree. I've had thought about creating a
SocketErrortype in the past. It might be worth looking at the thoughts the Python people have when they recently redesigned part of the their hierarchy (http://www.python.org/dev/peps/pep-3151/).Custom exceptions make error handling much messier. Suggest using
Eitherwhere 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.
Close this in favor of #151.
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.