4 ms·
Like others have said, in theory this is great. In reality, I never see custom exceptions being handled differently than whatever exception was wrapped. And I h
by greatpostman 4y ago
Like others have said, in theory this is great. In reality, I never see custom exceptions being handled differently than whatever exception was wrapped. And I have worked on some large distributed systems where failure is common. For new engineers these custom exceptions add abstract complexity and exception class hierarchy into a code base when it really isn’t needed.
- IshKebab 4y agoI disagree. I have seen plenty of code that is forced to match on the text of an exception because it uses a too-generic type. That said, I still wouldn't use a custom exception type in most languages simply because it's so tedious for a small pay-off. It's one of those things that you should do, but isn't really worth the hassle. Like putting alt text on HTML images. Do any languages with exceptions let you define new exception types at the throw site?
- Psyonic 4y agoI don't see how an exception type defined at the throw site would be significantly different than using the text of the exception to convey the type. Callers wouldn't know to expect it either way, so how would they be able to handle it effectively?
- vbezhenar 4y agoYAGNI principle should be followed here. Do not throw custom exception until you need it. If the time arises, do a simple refactoring. For libraries that's more nuanced and good unchecked exception hierarchy is a part of good API.