3

I have the following:

public void method(){

    try {
        methodThrowingIllegalArgumentException();
        return;
    } catch (IllegalArgumentException e) {
        anotherMethodThrowingIllegalArgumentException();            
        return;
    } catch (IllegalArgumentException eee){ //1
       //do some
       return;
    } catch (SomeAnotherException ee) {
       return;
    }
}

Java does not allow us to catch the exception twice, so we got compile-rime error at //1. But I need to do exactly what I try to do:

try the methodThrowingIllegalArgumentException() method first and if it fails with IAE, try anotherMethodThrowingIllegalArgumentException();, if it fails with IAE too, do some and return. If it fails with SomeAnotherException just return.

How can I do that?

Turing85
  • 18,217
  • 7
  • 33
  • 58
St.Antario
  • 26,175
  • 41
  • 130
  • 318

1 Answers1

7

If the anotherMethodThrowingIllegalArgumentException() call inside the catch block may throw an exception it should be caught there, not as part of the "top level" try statement:

public void method(){

    try{
        methodThrowingIllegalArgumentException();
        return;
    catch (IllegalArgumentException e) {
        try {
            anotherMethodThrowingIllegalArgumentException();            
            return;
        } catch(IllegalArgumentException eee){
            //do some
            return;
        }
    } catch (SomeAnotherException ee){
       return;
    }
}
Mureinik
  • 297,002
  • 52
  • 306
  • 350
  • 2
    @St.Antario This seems like a code smell to me - even though it is the right answer. If you are having to write code this way, you probably could refactor it to be cleaner. As far as I know, catch statements shouldn't be doing anything that could cause an exceptional situation. – crush Jul 24 '15 at 13:41
  • @crush __As far as I know__ I think that's not true, becuase somtimes you want to throw something more informative than, say, IndexOutOfBoundException – St.Antario Jul 24 '15 at 13:42
  • @St.Antario Explicitly throwing from inside the catch is not an exceptional situation. Calling some code that produces an exceptional situation from inside your catch is not ideal, though. I imagine you must be doing something like writing a log file to a resource that might not be available. A cleaner way to handle something like that would be to use a logging interface where the implementation handles the exceptions internally for example. – crush Jul 24 '15 at 13:45
  • @crush Not exactly, I'm trying to perform two different conversion stratefies. If the first failed, then try the second. – St.Antario Jul 24 '15 at 13:50
  • @St.Antario Trial and error conversion can be slow. Depending on what you're converting. it might be better to do some analysis on your data to figure out how to convert it before trying to convert it rather than going through a sequence of steps until you find one that works. Then, sometimes, you just need something that gets the job done. – crush Jul 24 '15 at 13:55
  • @crush Why? At runtime we don;t know about the actual type, so we need to try all convertions till we find a suitable one. – St.Antario Jul 24 '15 at 14:38
  • 1
    @St.Antario Of course you don't know the type...You'd analyze the data to make a guess about the right type before trying to convert. It could be faster to do it this way. Exceptions can be slow and costly. It really depends on the data you are converting, how many conversion methods you are iterating through, and if you need to handle a lot of operations quickly. – crush Jul 24 '15 at 14:51
  • @crush Now I understand what you meant. Thank you. – St.Antario Jul 24 '15 at 14:57