I think the question is more on if the implementation of how the jvm does exceptions somehow less affected by core count?
That is, the checked part is just a language implementation, right? The jvm doesn't really make much of a distinction. (This is meant as a check to my assumption.)
Yes, that's right, as static type checks generally are. However, the C++ performance issues are unrelated to whether exceptions are statically and/or runtime checked. Furthermore, Java exceptions are not particularly efficient, in particular because they collect the current stack trace on creation by default, which is a relatively expensive operation.
I thought you could tune away the trace on creation behavior.
Regardless, I'd be interested in seeing if this is a performance bottleneck. I'd guess it is only relevant on dataset processing. Closer you are to a place that legitimately can toss to a user, more likely you are to not care?
That is, if the common case of an exception is to stop and ask for intervention, is this a concern at all?
> I thought you could tune away the trace on creation behavior.
You can when you implement your own exception type, but not in general (and doing so would break too many things).
Exceptions are thrown and caught quite frequently in Java for "expected" cases, for example when attempting to parse a number from a string which is not a valid number. It's generally not a performance problem, and stack trace collection is probably heavily optimized in the JVM. Nevertheless, it's certainly still a lot slower than C++ single-threaded exceptions. You have to realize that even a factor of 100 slower may be unnoticeable for many use cases, because so much else is going on in the application.
That is, the checked part is just a language implementation, right? The jvm doesn't really make much of a distinction. (This is meant as a check to my assumption.)