Hacker News new | ask | show | jobs
by philf 5132 days ago
> You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.

What he completely ignores is the possibility to wrap exceptions to either aggregate them or to convert them into unchecked exceptions.

2 comments

But that's exactly one of the main points of the detractors of checked exceptions (of which I'm one): the only sane way of working with it is to subvert it.

Whether you convert the throws clause to a common supertype (which very soon converges to the base type Exception), or wrap everything in a RuntimeException, you are effectively emulating a language without checked exceptions. So what was the point in the first place?

"the only sane way of working with it is to subvert it."

Perhaps.

In my projects, I use wrapped exceptions to convert "what blew up" exceptions into "what to do about it" exceptions. A poor man's event routing. For example, I wrote an ETL workflow thingie that would retry, reset, restart, backoff (throttle) depending on what was failing.

I'd be totally game for pre declaring what exceptions your code will catch, harkening back to the days of "on message do this" type programming. Then the compiler can tell verify that all the thrown exceptions get caught by somebody.

Meanwhile, I've never had a problem with checked exceptions.

Methinks the real cause of angst over checked exceptions are all these mindless frameworks, APIs, libraries, strategies, design patterns, aspects, inversion of common sense, injection of nonsense, etc.

The complexity borne of the manner in which Spring, JPA, Hibernate, connection pooling, aspects, MVC, blah blah blah attempt to hide, obfuscate, decouple, mystify, pseudo architect "solutions" ... well, it's just insane.

Someone upthread off-handedly noted the irony of declaring all these exceptions only to have the main event loop eat an exception without any logging. Story of my life. Debugging silent death failures really, really sucks.

Which is why I work as "close to the metal" as possible and worry not about unchecked exceptions.

You can work with it or route around it when it doesn't make sense for you or the particular context i.e. it gives you choice. Additionally, I regard checked exceptions as automatic documentation.
Exactly. I've been using Java for 13 years and have yet to see a method signature with more than a handful of exception types thrown, let alone 40 or 80. I've told you a millions times not to exaggerate ;)
Thanks ! I just thought i was missing somehting , that Heisenberg did not mention exception wrapping. The funny thing about that technique is, that a lot of people do know it, they ususlly just print a strack trace and ignore the exception...
I sense some uncertainty on how to spell his name...
oops sorry for the typo ;)