Hacker News Reader

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.

View on HN

I 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?

I 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?

YAGNI 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.

Reply on news.ycombinator.com