throws

[jdgallag]

I have written a program with a method that looks like:

public method M (type arg, ... ) throws Exception1 {
...
}

How can I catch this exception? Can I have a different class that only catches exceptions generated by my other classes? An exception agent so to speak?

like in
main ...
ClassThatCausesExceptions c1 = new ClassThatCausesException();
ExceptionClass ex = new ExceptionClass [c1,...];

?

[masijade]

Whatever calls that method catches the exception, or declares itself to throw it, and then whatever calls whatever called that method needs to catch it or declare to throw it, or whatever calls whatever called whatever called it .....

[Steve11235]

Look at Sun's tutorial.

Briefly, every *method* is required to catch any Exception's that can occur within it, using

try {
// code that can cause Exception's
}
catch (SpecificException ex) {
// do something about the exception
}
finally { //this block is optional
// some code that *ALWAYS* gets executed
}

OR

the method has to list the Exception's it throws using a "throws" clause.

Note that I said Exception, which is the base class for all sorts of more specific exceptions. The base interface is Throwable. Along with Exception, there is RunTimeException, which is the base class for many specific exceptions that *do not* have to be listed in "throws" clause but could still occur (like NullPointerException).

I hope I gave you just enough to get you to read the tutorial ;-)

[Eranga]

Adding More: To handle your own exceptions, simply extends that Exception base class.

class MyException extends Exception {
     // Public methods to handle exception
}

[Steve11235]

To handle your own exceptions, simply extends that Exception base class.

I think Eranga meant to *create* your own exception classes, which is also a good practice, since whoever invokes your methods will know exactly what any exceptions thrown by that method mean.

[CJSLMAN]

Here's a link that explains all about exceptions and how to throw them correctly:

Lesson: Exceptions (The Java™ Tutorials > Essential Classes)

Luck,
CJSL

[emceenugget]

classes don't throw or catch exceptions, methods do

[Eranga]

classes don't throw or catch exceptions, methods do

Is anyone talking about this here, or you just want to let it know to our thread starter. :) I thought I've misspell something in my explanation.

[Eranga]

I think Eranga meant to *create* your own exception classes, which is also a good practice, since whoever invokes your methods will know exactly what any exceptions thrown by that method mean.

Yes Steve, may be I use the wrong word. :) Thanks for the commenting on my mistake.

[Steve11235]

Not a mistake, just a mistranslation...

[emceenugget]

i mentioned my post because the writer makes a reference each to both classes creating and catching exceptions, which may be due to misuse of words, but i think it's more due to just not being familiar with what exceptions are and how they work:

Can I have a different class that only catches exceptions generated by my other classes?

and

"ClassThatCausesExceptions c1 = new ClassThatCausesException();"

[toadaly]

It sounds like what you want is the equivalent of a globally registered interrupt handler. That isn't how exceptions work, and the only equivalent to it in Java is a shutdown hook.

If you want something like that, what you would need to do is create a new Exception (which it looks like you did with 'Exception1'), but have it's constructor register with a global singleton of some kind. The singleton can then be notified of all 'Exception1"s that get created. Then, put a try catch around everything, and convert any Throwables into your new Exception1 class.

[Steve11235]

Emcee-

I think the OP gave up on this post a while ago. Two of us pointed them to the tutorial; hopefully, they took that advice.

Toadaly-

That's an interesting idea, having a base exception class whose constructor calls a static method. The problem is, the Exception has to be allowed to work its way through the invocation stack, so every method has a chance to catch it. And, we can't change the definition of Exception, so only home-grown exceptions could be handled that way.

One way to create a last line of defense is to add the following code around the the logic that drives the rest of the application. Note that this won't do *anything* about other threads that terminate because of an exception; each thread has to be coded this way.

try {
  // base logic
}
catch (Throwable t) {
  // handle *all* Throwable's, including RuntimeExceptions
}
finally {
  // resource deallocations
}

Catching Throwable, which is the interface for Exception, guarantees nothing can get through.

[masijade]

Catching Throwable, which is the interface for Exception, guarantees nothing can get through.

One note though, Be very careful using this type of approach, as RuntimeExceptions, generally, should not be caught. In some instances they can easily be caught and handled (i.e. catching a NumberFormatException when parsing a CSV and expecting an Number when you get some other String, and then aborting the parse, or using a default value if that is acceptable, but keeping the program running) but should not be caught and/or cannot be handled logically/effectively in many others (i.e. a ConcurrentModificationException which indicates a program logic error).

Edit: Although, if it is a program that runs without direct user interaction, then you should, of course, catch all exceptions to ensure that they get logged properly, but then you should, IMHO, rethrow the caught RuntimeExceptions.

[Steve11235]

I should have stated the obvious when I laid out a global catch:

All caught exceptions must be fully handled or re-thrown.

Thanks for pointing that out.