4 ms·
"For example, if you indiscriminately catch Exception (instead of CreditCardExpiredException, SuspiciousActivityException, CardTypeNotSupportedException and so
by TeaBrain 2y ago
"For example, if you indiscriminately catch Exception (instead of CreditCardExpiredException, SuspiciousActivityException, CardTypeNotSupportedException and so on) in order to recover from a credit card transaction failure, you may inadvertently catch SQLException as well, but that is a different type of error"
All of the above examples of custom exceptions are great examples of things that should never be handled by exceptions. If the author was using a library that really threw exceptions like this, then it would probably be best to just find a new library which isn't arbitrarily throwing exceptions to create control flow logic.
- PaulHoule 2y agoThere is nothing wrong, I think, with having application-oriented exceptions, but you are going to either catch them individually or make them derive from some root like CreditCardException. Real life does not respect encapsulation, that is, it is not really your application's business to know that such a thing as a SQLException exists, other than how to log it, if SQL is hidden beneath a DAO layer. I mean, just because the beautiful architecture of your application doesn't have things like backhoes cutting through fibers in it, doesn't mean those things can't happen to you. There are a lot of things that will happen to your application that it can't understand and the best it can do is: (i) protect its own integrity (use finally) and (ii) abort, retry or ignore and (iii) hopefully have the wisdom to choose the right one of those.
- deleted 2y ago[deleted]
- breadwinner 2y ago> should never be handled by exceptions So you prefer to check for errors after every function call? That's what you had in C language, and the problem is that the logic gets buried inside all the error checking, and that makes code hard to read (and write).