I recently discovered that the method `StructuredTaskScope.Subtask.exception()` returns a `Throwable` instead of just `Exception`. This means that it can return any `Throwable`, including serious errors like `OutOfMemoryError` or `StackOverflowError`. With this in mind, I think it might be better if the method were renamed to `throwable()`. I've also reached out on the Loom-dev mailing list to discuss this.
4 Answers
I think using the name 'exception' isn't that unusual when talking about Throwables in general, since many people do refer to them that way. Renaming it to 'throwable' would certainly make it clearer, but unless the change is super easy, I doubt it'll happen.
Why even have methods returning error types if the recommendation is not to handle them?
I actually think it's alright. The return type is pretty self-explanatory. My real issue is that the API tends to swallow errors like `StackOverflowError`, `OOM`, and others by default. It’s not a great idea to suppress those exceptions, as they usually indicate serious bugs. It’s better to fail fast, and if developers want to ignore these errors, they should do it intentionally with some extra code.
Seems like you’re not alone in this thought. I’ve seen more responses agreeing with your point about method naming conventions, and switching it up now could really just add unnecessary confusion.
It’s a classic case of Java confusion. So many terms in Java are misnamed. Like, everything uses references and yet we still have `NullPointerException`. If you look at things like `RuntimeException`, it's all thrown at runtime, making the name kind of pointless. The naming issues are definitely a longstanding quirk of the language.
So true! Seems like it's always been this way, and although it should get better, they just stick to the names that have become the norm. I noticed you've gotten more input on your mailing list post about this too!
That makes sense! Is there a workaround for the default behavior you mentioned?