views:

701

answers:

8

I was writing some code, and I notice a pattern in the exception handling that got me thinking:

try{

        // do stuff... throws JMS, Create and NamingException

} catch (NamingException e) {

        log1(e);
    rollback();
        doSomething(e)
} catch (CreateException e) {

        log1(e);
    rollback();
        doSomething(e)
}

Where JMSException would be handle some where up in the stack.

Would it be to just write:

try{

        // do stuff... throws JMS, Create and NamingException
} catch Exception[NamingException, CreateException] e) {

        log1(e);
    rollback();
        doSomething(e)
}

instead of putting it in tu a helper method:

try{

        // do stuff... throws JMS, Create and NamingException
} catch (NamingException e) {

        helper_handleError1(e)
} catch (CreateException e) {

        helper_handleError1(e)
}

Notice that I want to propagate stacktrace of the original JMSException, and I don't "feel like" creating an new JMSException with a third catch clause :)

Any toughs? Is this an extreme situation that would only pollute the syntax of Java, or just a cool thing to add?

A: 
Dev er dev
A: 

I suggest using the "Execute Around" idiom.

Tom Hawtin - tackline
What is the "Execute Around" idiom?
Avi
I don't think that really fits his case; he wants at least one Exception to escape and propagate up the chain.
Greg Case
Avi: Good question. http://stackoverflow.com/questions/341971/what-is-the-execute-around-idiom
Tom Hawtin - tackline
Greg: I don't see that in the original question, and I don't see that as a problem anyway.
Tom Hawtin - tackline
A: 

Try this:

try {
  ...
} catch ( Exception e) {
  if typeof(e) not in ('MyException', 'SpecialException') {
    throw e
  }
  doSomething()
}

(pseudo code)

Marcel
It looks good as pseudo code, but is not much practical when converted to real code ;(
Dev er dev
+1  A: 

In first place,

} catch Exception[NamingException, CreateException] e) {

lacks a '(' char.

In second place, why "Exception[NamingException, CreateException] e" and not just "[NamingException, CreateException] e"?

The idea may be nice, but it needs some polishing. For example, suppose I declare "MyException" class with a function "doYellow()" and a "OtherException" class with a function "doYellow()". Would such function be allowed(considering there is no "doYellow()" function in the superclass). If so, would it be allowed if "doYellow()" was declared on only one of them? Is that what the "Exception" before the [] chars is for? Also, suppose there is this declaration:

void doYellow(NamingException e);
void doYellow(CreateException e);

(note that they are different functions) would it be allowed to be called?

You really should provide further details. However, it can be useful in some cases(it's not rare)

luiscubal
+4  A: 

They are considering an extension of this type for Java 7.

See: http://tech.puredanger.com/java7#catch

Darron
A: 

Another way to do.

Convert a low level exception to your own high level exception, and handle it.

try{
    try{
        // do stuff... throws JMS, Create and NamingException
    } catch (NamingException e) {
            throw new MyException(e);
    } catch (CreateException e) {
            throw new MyException(e);
    }
} catch (MyException e) {
    // something on e or e.getCause();
}
Dennis Cheung
A: 

Why not just

try
{
   // do stuff... throws JMS, Create and NamingException
}  catch (JMSException e) 
{   
   if (e instanceof CreateException || e instanceof NamingExcption)
   {    
     log1(e);
     rollback();
     doSomething(e);
   }
   else
     throw e;
}
Paul Tomblin
Sometime you may not want to do it for two reasons.1. They may not have same common parent exception.2. The re-throw class may not a checked exception declared on the interface.
Dennis Cheung
+3  A: 

As long as we're making up syntaxes, here's how I'd like to see it:

try
{
   // do stuff ...
}
catch (NamingException e)
catch (CreateException e)
{
   log1(e);
   rollback();
   doSoemthing(e);
}

Similar to the the fallthrough of a switch statement or C# using block. Of course, there's a problem here with the variable e declared twice, but I think something could be worked out.

Joel Coehoorn