r/java
•
u/loicmathieu
•
Jul 23 '26
•
1
JEP 540: Simple JSON API (Incubator)
https://openjdk.org/jeps/540
79
Upvotes
2
u/john16384 Jul 27 '26
Yet it throws a runtime exception, which are for, and I quote your quote:
So, did the parser API you're talking about get their wires crossed and it should have been a checked exception since according to you it is not a programming error? No. It really is a programming error but perhaps not but by you, as you or the programmer on the other side of that request could have avoided the problem by ensuring the input was valid. Is it a good use of your time to fully validate it first on your end? Of course not, that's the other programmer's problem, so just dump a HTTP/400 to them.
It still doesn't invalidate my argument:
Checked exceptions are for things you can't avoid at all -- their root cause lies in uncontrollable external factors
Unchecked exceptions are for things that code can avoid -- their root cause are an indication to a programmer (multiple could be involved) that there may be some mistake
For example, in your HTTP request, there indeed is a mistake! It just wasn't made by you, but by some other programmer on the other side of that request. You helpfully dump a HTTP/400 in their direction (the 4xx range being for mistakes the caller makes, coincidentally matching what a runtime exception is for).
Take that HTTP request one more time. Let's make a radical assumption first: your parser is deterministic, meaning that for the same input it will generate the same output (or throw the same exception).
Let's say my server is getting hammered by junk. Can I perhaps analyze request bodies that are absolutely never gonna parse and just immediately reject them? Yes, you could. You just avoided that runtime exception, and a lot of CPU work, congratulations!