5 ms·
I can't agree with any of these points. 1. You don't know which exceptions will be raised in advance. Anything that involves IO can fail in a plethora of ways,
by eweise 4y ago
I can't agree with any of these points.
1. You don't know which exceptions will be raised in advance. Anything that involves IO can fail in a plethora of ways, and you don't even know which calls involve IO (e.g. a library might choose to cache something on disk).
Not sure how this relates to the code design decision
2. Consumers of your code will not know how to deal with those exceptions.
Not sure the point here but if the argument is that the caller won't know how to deal with the third party exception, I disagree. Typically it just needs to return a single exception type that wraps any underlying cause. Caller can just either decide to deal with it or rethrow.
3. Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of action is to crash, which happens by default.
If the database is unresponsive do you want to crash your program? I wouldn't. I'll usually retry until its available.
4. You debug those exceptions by looking at stack trace. Adding extra levels just to give a fancy meaningless name to an exception does not help.
Really don't think an extra trace in the stack is a reason to not create a well defined contract.
5. The whole point of exceptions is to propagate. Parthenon essentially suggests converting exceptions into return values.
I didn't see anywhere in the doc where they mentioned converting exception into return values. Wrapped exceptions are still exceptions.
- lmm 4y ago> Really don't think an extra trace in the stack is a reason to not create a well defined contract. It absolutely is IMO. Stack traces are the main reason to use exceptions at all, and having multiple layers of useless wrapping around them is one of the biggest frustrations when trying to understand and debug an issue.
- vbezhenar 4y agoIf the database is unresponsive, I would prefer to return 5xx to the caller as soon as possible. May be this service is not so important and it's better to present to user an incomplete page rather than waiting for hours or days until database is available. If it is important, caller will call the service until he got response. Again: fail fast. Even in distributed systems. Unless you're 100% sure that you know better how to handle this particular issue.
- eweise 4y agoTotally agree about returning a 5XX error. In my app that would be a single RetryableException back to the caller instead of the internal db error.
- hbrn 4y agoUgh. You should never call something "RetryableException". 1. You are in no position to decide for your customer whether exception is "Retryable". 2. For cases where you are in that position, you should just retry automatically. 3. RetryableException tells absolutely nothing about what happened. It's no better than raising MondayException for exceptions that happen on Monday.