0

Is it possible to have all of my try/catch code catch the superclass Exception, then have some util class find out what type the exception is so I may log the specific type? For example:

CustomLog{ Logger log= .... public static logTrace(Exception e){ log.debug("name of exception: " + e.????); } } SomeOtherClass{ try{ }catch(Exception e){ CustomLog.logTrace(e); } }

Or is there a better idea for what my goal is (to only have generic Exceptions in the code)?

Improve this question
4
  • 3
    It is possible, but is it a good idea? What sort of code is in the try {} to motivate this solution? Edit: NM; misunderstood. Commented Mar 21, 2011 at 21:17
  • What package is providing Logger? log4j? slf4j? Plain old java.util.logging? Commented Mar 21, 2011 at 21:24
  • @Bittrance: but I think that is a good point. What problem will having only 'generic' Exceptions actually solve? You want to catch and handle exceptions in a specific way, that is the point. Commented Mar 21, 2011 at 21:33
  • Why do you only want the class/name of the exception? If you do an e.printStackTrace() or pass the Exception to a Logger method, you'll get a printed stacktrace, which is much more valuable. Commented Mar 21, 2011 at 21:42

4 Answers 4

Reset to default
2

If your intent is simply to log information about the exception, then just pass the Exception to the appropriate logging method and let the logger do the work for you:

log.error("Exception caught", e)

Most logging APIs support a Throwable as an argument to their debug(), error(), etc. methods. No need to reinvent the wheel unless you have a real reason to do so.

Regarding your questions about architecture (the "is there a better idea" part), there's a basic rule you can follow: if you can do something about the exception (e.g. rollback a transaction), then catch it and do what's appropriate. If you can't recover from it, then throw it from your method and let the caller take care of it.

Ultimately, exceptions that are unrecoverable will propagate up the stack to the container (whether that's a main method, servlet container, or something else). The container can then write logs, send alerts, or handle the exception in some other way.

Don't use a general Exception (like you suggested). Don't catch something, log it, and then go on processing like it didn't happen (unless that really makes sense for your specific situation). If you can't handle the exception, throw it from the method you're in and let a method higher up take care of it.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

@bmw0128 - No problem. Search StackOverflow for exception handling and read through some of the answers. They'll provide you with some insight; this topic has been covered quite a bit.
I wish I could give you two votes for the "Don't use a general Exception" advice" "catch (Exception e) { }" is the bane of my existence. That and "public void foo() throws Exception" makes me want to hurt something.
0

Try:

e.getClass().getName()

However if it is wrappered Exception you may want to consider logging it's cause.

Improve this answer

Comments

0

Exception.toString() will give you what you want, I think.

Improve this answer

Comments

0

As long as CustomLog has access to the specialized class of the Exception then yes.

You could even do something like this in your CustomLog code:

logTrace(Exception ex) { try { throw ex; } catch(CustomException ex) { // specialized handling of CustomException } catch(Exception ex) { // unknown exception } }
Improve this answer

1 Comment

One quick disclaimer: If all you want to do is log the exception, really the toString(), getMessage() and such methods are probably all you would want to use. The Exception classes themselves should provide meaningful results to those calls. You typically wouldnt want to push this logic up into a logging package.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.