Herb states that
if a method is capable of causing an exception that it does not handle, it must specify this behavior so that callers of the method can guard themselves against that exception. You do this by including a throws clause in the method’s declaration. A throws clause lists the types of exceptions that a method might throw. This is necessary for all exceptions, except those of type Error or RuntimeException, or any of their subclasses. All other exceptions that a method can throw must be declared in the throws clause.
And for the throw
However, it is possible for your program to throw an exception explicitly, using the throw statement. ThrowableInstance must be an object of type Throwable or a subclass of Throwable. Primitive types, such as int or char, as well as non-Throwable classes, such as String and Object, cannot be used as exceptions. There are two ways you can obtain a Throwable object: using a parameter in a catch clause or creating one with the new operator.
My problem is that can you help me understand the quoted text in something more easier to grasp/comprehend?
But in case it helps, here are a couple of examples of their use. As you'll see, while they are both related to exceptions, they are used in completely different ways.
My fault i should have expressed the concern more better.
Anyway, the problem is that lets say divide by zero exception. You can try to divide a number by zero but since it will fail therefore the exception is caught by the catch block and the program flow continues rather than stopping if there was no catch block. Now i would like to know what are the conditions in which a program can throw exceptions explicitly, because according to Herb, "Null pointer exception" is explicit exception, so based on this analogy does this mean implicit exceptions are equivalent to java run time exceptions? im sure im missing with something here but cant spot what it is.
Then for the throws clause, Herb writes "If a method is capable of causing an exception that it does not handle, it must specify this behavior so that callers of the method can guard themselves against that exception." Now, how would i know or come to know which exceptions my method might throw that its not capable of handling?
In my opinion, a method should never create an Exception and handle it. That is simply an inefficient way to write an if‑else statement.
You may handle an Exception anywhere, provided you can say, “If an XYZException occurs I shall do PQR.” If you cannot say that, then you should consider propagating the Exception higher up the call stack, which you can do by declaring the Exception in the documentation comments or a throws clause, if you know what sort of Exception it might be. If the Exception is checked type, then you must know about it because the compiler will otherwise give an error. If the Exception is unchecked, you might not expect it. You do not necessarily know that you are going to suffer a NullPointerException, for example.
Waht you ought to do is declare all chkecd Exceptions which the program can throw with a throws clause, and add a @throws tag to your documentation comments for any exceptions of any sort which you might expect. Let’s elaborate Matthew’s example:-Note the unchecked IllegalArgumentException need not be included in the throws clause but the checked PQRException is included, and both exceptions are described in the documentation.