Well, it depends on who you classify as "programmers". The JVM was built by programmers, so every exception it throws could be considered a programmer thrown exception. Then again, your own code is run by the JVM, so every exception you throw could be said to be a JVM thrown exception.
It's a bit of a strange distinction to make.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
No, the exam does occasionally make a distinction between exceptions that are (generally) thrown by the JVM and those that are explicitly thrown in application code.
I've always found the key is simply remembering what the exceptions actually mean - under what circumstances they are thrown. If you properly understand this then it's usually pretty obvious. For example: NullPointerException. That's thrown by the JVM whenever you try to dereference a reference with a null value. Whereas an IllegalArgumentException is thrown when a value passed in to a method isn't valid. But the JVM is never going to know that - that depends on application logic. It's the result of code like this:
So I never bothered learning which category exceptions came into. I learned what they were for, and worked it out from that. If you can look at a piece of code that doesn't have a new XyzException() in it and say "that might throw an exception", then it must be a JVM thrown exception.
The Exception class has a getStackTrace method that returns a StackTraceElement array. The StackTraceElement class has a number of methods that return the file name and method name of the source of the exception. Conceivably this could be used to determine whether the exception was thrown by a JDK class or a "programmer" class. I am not sure if this is what you are looking for.
Thanks Matthew , I understood what you have said but still i hava a small doubt, i.e. we can throw both JVM thrown exceptions and Exceptions thrown by programmers in our program by using the throw keyword, then how can we exactly differntiate between these two. Do we have to focus on what exactly the exception means and its purpose as you have said and from that distinguishing these exceptions as JVM thrown exceptions or Exception thrown by Programmers or do we have to do anything else. I think if this doubt is cleared the question is solved. Thanks .
It's like Stephan said: it's a meaningless distinction. There is no meaningful answer to your question. And since you posted it in the forum about certification exams, I'm pretty certain you won't ever find that question on one of those exams.
And I don't think it's really meaningless, either. It's useful to know, when you are studying a stack trace for a NullPointerException or ClassCastException, that you are not looking for a line that says "throw new NullPointerException". Usually. When it's an exception thrown by the JVM, it's important to understand what it looks like in your code, and to mentally fill in what the JVM does in response.
Joined: Mar 05, 2008
Parsuram Samal wrote:Thanks Matthew , I understood what you have said but still i hava a small doubt, i.e. we can throw both JVM thrown exceptions and Exceptions thrown by programmers in our program by using the throw keyword, then how can we exactly differntiate between these two.
Any exception (or Throwable really) can always be thrown intentionally by a programmer who chooses to do so using the throw keyword. (provided they obey the usual rules, declaring or catching checked exceptions, etc.) The key is to understand the other situations where an exception gets thrown by the JVM, without any "throw" appearing in source code.
Digging this thread up as I was reviewing this objective... I too was confused, not finding any distinction in the API for the listed exceptions and errors, then remembered seeing a table in the Sierra/Bates SCJP 6 Study Guide.
Like others have said, when you understand when/why each is thrown, it becomes fairly obvious whether they are thrown by the JVM or programmatically, but having a list helped dispel any doubts I had, and made it more obvious to me why they were categorized that way.