How to differentiate between Programmer and JVM Exceptions

Answer 1

I'm not sure what you mean by JVM exceptions. These are all runtime exceptions that may be thrown by the programmer at any point (exception AssertionError), though it is considered poor style to throw certain exceptions like NullPointerException. The point is, there's no one quality separating the two categories you mention other than their typical usage. All the runtime exceptions extend, either directly or indirectly, RuntimeException.

From the JavaDocs for Throwable:

Only objects that are instances of this class (or one of its subclasses) are thrown by the Java Virtual Machine or can be thrown by the Java throw statement.

Because this same superclass defines all exceptions thrown by either the JVM or a programmer, you can't easily distinguish the two.

Answer 2

I don't think you will find a complete list, since there is no clear distinction between jvm and programmer initiated exceptions, apart from a few special cases:

• most Error classes are thrown by the VM, due to internal or external causes. The one exception ThreadDeath, is thrown in a thread when that thread is stopped, and is kind of a "hack" to get the thread to unwind it's stack and exit.
• most checked exceptions relate to environmental problems that lead to failure of some operation, but may be resolvable and are non-fatal to the JVM (IOException, SQLException, RemoteException) come to mind.
• the remainder, unchecked exceptions, are a combination of both jvm and programmer initiated exception. For example, the JDK throws IllegalArgumentException when method parameters are not to spec. Is that a JVM exception or a programmatic exception? It unclear if your definition of JVM exceptions includes the JDK or not. ArrayIndexOutOfBounds is generated for illegal array accesses, generated by the JVM, but it's also thrown in some apis, e.g. Track.get from java.midi. (Although this can be argued as poor form, and the superclass IndexOutOfBounds should have been used instead.)

Answer 3

You cannot do this statically because no such distinction exists.

Any exception defined in the standard Java class libraries may be thrown by application or third-party library code. In some cases, it is a bad (or even terrible) idea to throw a standard exception, but in others it is the recommended thing to do.

The only possible way to distinguish between an exception thrown by the JVM and by application code is to examine the stack frames from the thrown exception to figure out what class instantiated the exception. (Strictly speaking that doesn't tell you where the exception was thrown ... but it is close enough given that exceptions are nearly always instantiated and thrown in the same statement.)

But even this is not a particularly useful thing to do. I mean, what is the semantic difference between an exception thrown by application code and the class library? It certainly doesn't say anything about the root cause of the problem.