Enthuware

> Taking the length of null as if it were an array.

what does it mean? For example?

int[] intArray = null;
System.out.println(intAray.length);

thank you

I would like to suggest adding the expressions checked exception ('thrown by the application') and unchecked exception ('thrown by the JVM') to the explanation, as these are also widely used. E.g. OCA Java SE 7 Programmer I Certification Guide by Mala Gupta and Introduction to Java Programming by Y. Daniel Liang both contain them.

Not sure what you mean by "checked exception ('thrown by the application')" because it is not necessary that a checked exception is always thrown by the application and unchecked exception is always thrown by the jvm.

I think I misunderstood this one.

So, ClassCastException, NullPointerException, SecurityException, IllegalStateException, IllegalArgumentException are all unchecked (runtime) exceptions. Whether an exception is checked or not has no relevance to what throws it - the JVM, or the application. Correct?

The question asks me to identify exceptions 'usually thrown'. Here's what the books I read have to say:

IllegalArgumentException
Gupta:

programmers usually use this exception to validate the arguments that are passed to a method.

OK, clear.

Liang: just states that an application can create an instance of it and throw it. Doesn't give clues to usual usage. (Says runtime exceptions are usually thrown by the JVM.)

IllegalStateException
Gupta:

As an author of code, you can throw IllegalStateException...

To me, this just means it's an option for me, not anything done usually.
Liang: Doesn't even mention it.

I understand the question and the answer. I'm just unsure as to where I should have learnt the info contained within.

A quick way to determine who should throw an exception is to see if the exception extends java.lang.Error. Errors are always thrown only by the JVM.

What is your opinion about "AssertionError" and NumberFormatException? are they thrown by JVM or program/application?

According to K&B book, both of them are thrown programmatically.

AssertionError is never thrown programmatically/explicitly by a programmer (A programmer legally can, but should not). A programmer writes assertions and if the assertion fails, AssertionError is thrown by the JVM.

NumberFormatException is never thrown by the JVM automatically. It is thrown by the programmer explicitly.

HTH,
Paul.

Thanks, for your reply.

SecurityException extends RuntimeException: Usually thrown by the JVM.  It is thrown by the security manager upon security violation. For example, when a java program runs in a sandbox (such as an applet) and it tries to use prohibited APIs such as File I/O, the security manager throws this exception.

Wrong. SecurityException is never thrown by JVM, it's thrown by the java runtime libraries.

It is correct. It is not thrown explicitly by application code but thrown by the security manager, which is part of the jvm.

Security manager (java.lang.SecurityManager) is part of jrl, not jvm. Formulations have to be exact. Any exception, which raised by "throw new " in java code can't be considered generated by jvm. Your answer is incorrect.

You are right. This has been updated.
thank you for your feedback!

enthuware.ocajp.i.v7.2.1017 says SecurityException is thrown by the application programmer

enthuware.ocajp.i.v7.2.1368 still says SecurityException is thrown by the JVM

Fixed.
thank you for your feedback!