Hacker News Reader

Comment by bhauer | Hacker News Reader

Agreed. I feel the key word in dealing with exceptions is "exception," meaning something uncommon, which is a foreign concept in some codebases, where exceptions are used as routine flow-control.

Throwing an exception in Java is a non-trivial expense since the constructor for Throwable populates a stack-trace structure for the current thread. If you're using exceptions as a routine flow-control mechanism, you're incurring that cost too frequently.

Like you said, sure, tune the performance of this new feature because it's part of the standard library and should be reasonably well-tuned. But if people are frequently throwing NPEs, they should consider alternatives such as simple null checks.

View on HN

> Throwing an exception in Java is a non-trivial expense since the constructor for Throwable populates a stack-trace structure for the current thread. If you're using exceptions as a routine flow-control mechanism, you're incurring that cost too frequently.

Unfortunately, the JVM has special code to detect this case (!) and stop recording the stack trace after a while (!!). Then when you go look at your log to see why the system isn't working, you see only `NullPointerException` without the expected stack trace, and you have to guess where it's coming from (after wondering for a few hours why the stack trace went missing, only to find the explanation at https://stackoverflow.com/questions/2411487/nullpointerexcep...).

The fact that anyone ever thought it would be worthwhile to implement an optimization like this is very telling.

I'm not exactly sure what it tells us, but it definitely tells us something.

> exceptions are used as routine flow-control Unfortunately, this approach is encouraged by some popular frameworks, for example a ResponseStatusException in Spring 5

And even the JDK itself. java.lang.InterruptedException comes to mind.

InterruptedException is sort of necessary evil, esp. when it comes to concurrent data structures.

InterruptedException are rare (very) and used mostly to signal termination attempt. LockSupport.parkNanos doesn't throw the exception (unlike sleep, and sleep should never be used in code) but the interruption signal/flag has to be respected somehow. Most of the time is rethrow in library code or bailing out with IllegalStateException in 'userspace'

I think that it could be done better. .NET's CancellationTokens are a step in the right direction, though sadly just one step. You can check if cancellation is requested, but there's also a method for asking the token to throw a CancellationException if cancellation has been requested, and this is how all the abstractions around threading do it.

But it's reasonably easy to imagine ways to produce an API that only uses tokens like that instead of using exceptions to signal cancellation/termination requests. And I suspect, given how many bits have been spilled trying to explain to people just how they're supposed to deal with InterruptedExceptions, that the resulting system would have better ergonomics.

Long story short, I don't know that it's that InterruptedException was a necessary evil so much as that people were still fairly new to this whole exceptions thing when Java came out, and it's really hard to get subtle things like this right on the first try.

Reply on news.ycombinator.com