10 ms·
> Just because it's useful to wrap exceptions in 5% of the cases doesn't mean you should wrap the rest 95% just in case. YAGNI. I'm going to curse here, but ..
by P5fRxh5kUvp2th 4y ago
> Just because it's useful to wrap exceptions in 5% of the cases doesn't mean you should wrap the rest 95% just in case. YAGNI.
I'm going to curse here, but ... fucking seriously.
If I get a .net ADO exception coming out of a 3rd party library it's absolutely not going to shock me or throw me for a loop. But do you know what IS a pain in the ass? Using 3 different libraries, all that wrap that same ADO exception in their own custom exception.
- hbrn 4y agoHaha, that's actually a good point. A single problem can affect dozens of modules, each having a different wrapper. If my db goes down, I very much prefer to see a single DatabaseConnectionFailed than a multitude of FailedToSaveObject, DatabaseError, CannotLoadData, IOError, SomethingIsWrongThisShouldNeverHappen, DBHostUnavailable all over the place. Good luck navigating through the noise and isolating those.
- eweise 4y agoThe article talks about solving that exact issue by wrapping all of those different exceptions so that you don't have to deal with them. Much easier to catch a single ThirdPartyInternalFailure exception than catch all the internal exceptions that could have caused an internal failure.
- Misdicorl 4y agoWhen library 1 through 10 take this approach to wrapping a common exception you get the above behavior. Obviously a single library should have a coherent internal story
- z3t4 4y agoWhat do you use libraries for if not for the abstraction layer?
- P5fRxh5kUvp2th 4y agoWell it certainly isn't so I don't have to understand what an ADO exception is.