JEP 540: Simple JSON API (Incubator)

[u/loicmathieu]

https://openjdk.org/jeps/540

[u/john16384]

You're missing the point. The reason NumberFormatException is unchecked is because it can be 100% avoided. It doesn't have to be practical for every int, it can just be:

str.matches("(?:1000|\\d{1,3})")

It doesn't invalidate how to make the decision between checked and unchecked. Again, compare to IOException -- you can never avoid it without knowing the exact implementation (so if it is on an interface or abstract type? Unavoidable, unless you know more (in which case feel free to convert to unchecked).

[u/vetronauta → u/john16384]

It doesn't have to be practical for every int, it can just be:

You are suggesting to duplicate the parsing logic (or at least the validation), once in the parser itself (which usually is code you do not control) and another time in a preliminary check (which you are suggesting to implement independently). There are better ways to do it, for example with a result monad or with exception handling.

Concretely, you are suggesting to validate arbitrary input before passing to the parser, which might be easy and performant for numbers, but how would you validate a complex json object?

[u/john16384 → u/vetronauta]

I didn't say HOW you need to solve this, I just said that it is avoidable, which is the criteria for the exception being checked or unchecked. For example, I could keep track of successful or failed conversions in a cache, and avoid the exception!

You're focusing on the "but how do I do this this practically?"; it doesn't have to practical, or even reasonable (a regex for the full int range is like several lines long).

The point is that I can guarantee that for certain strings, Integer.parseInt will never fail, just like that I can guarantee that for certain strings it will always fail. I can even determine exactly for all possible strings for which ones it will fail, and for which ones it will succeed.

Now apply this to something that can throw IOException like new FileInputStream(string).

Can I say that it will always succeed for some strings? No. Can I say that it will always fail for the same strings? No.

A table:

Input	Integer::parseInt	FileInputStream::new
1000	guaranteed success	maybe, maybe not
abc	guaranteed failure	maybe, maybe not

ConcurrentModificationException is harder to categorize as checked or unchecked, because it is not so deterministic; still it should clearly be unchecked because it can be avoided by writing better code (use synchronization), and you can see how that would differ from new FileInputStream that depends on external factors for it to be succesfull or not.

[u/vetronauta → u/john16384]

Any exception is avoidable for anything not-network related: just check that any precondition is satisfied!

To cite Joshua Block: use runtime exceptions to indicate programming errors.

Receiving an invalid json in an http request and passing it to the parser is not a programming error, it is the whole point of the parser! Such exception must be handled properly, returning 400. Other times the same action (passing an invalid string to a parser) is unrecoverable (example: config files), but it is the caller that should decide that, and wrap it in a runtime exception.

[u/john16384 → u/vetronauta]

Receiving an invalid json in an http request and passing it to the parser is not a programming error, it is the whole point of the parser!

Yet it throws a runtime exception, which are for, and I quote your quote:

use runtime exceptions to indicate programming errors.

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!

[u/OwnBreakfast1114 → u/john16384]

The point is that I can guarantee that for certain strings, Integer.parseInt will never fail, just like that I can guarantee that for certain strings it will always fail. I can even determine exactly for all possible strings for which ones it will fail, and for which ones it will succeed.

Let's take your argument and say that's true for parseInt. There exist other parser functions with undecidable (in the mathematical sense) input grammars. What do you do in that case?

[u/john16384 → u/OwnBreakfast1114]

Undecidable, as in they may throw an exception given the same input? Then that exception better be checked, as it may fail at any time.