Which is the style professional programmers use, using try and catch or adding the error handling in the code?

Question

Which one should be preferred over the other? Example:

class Example {
    int[] A = new A[5];

    void setArray(int item, int index) {
        if(index < 0 || index >= 5) {
            System.out.println("Index out of bounds");
        } else {
            A[index] = item;
        }
    }
}

or this one?

class Example {
    int[] A = new A[5];

    void setArray(int item, int index) {
        try {
            A[index] = item;
        } catch (ArrayIndexOutOfBoundsException e) {
            System.out.println("Index out of bounds");
        }
    }
}

I would probably use the first approach, (but throw an IllegalArgumentException when out of bounds). If the spec would really say *just print "index out of bounds"* I'd say both approaches are just as readable / maintainable / easy to get right, so either one is fine imo. — aioobe, Jan 21 '13 at 07:59

score 3 · Accepted Answer · edited May 23 '17 at 11:49

When a language has good support for exceptions (like C# and Java do), throwing and catching exceptions is the most common way of handling exceptional cases.

The reason is that it makes the logic of the code clearer: methods can be written for the general case (without bothering to resolve error codes and such) and only the few methods that actually have enough context to handle the unusual case will also contain the code to do so.

Your example doesn't demonstrate what I'm saying because you've caught the exception at the same level where it happened. In practice, exceptions are useful because they are thrown a few levels above, some of them even reaching near the top level of the program, aborting all the methods that were going to be called by that level afterwards.

The following explanation will hopefully shed some light on the importance of exceptions, when they are used properly:

First off, consider that an error message saying array index out of bounds is meaningless to the user. Even simply displaying another kind of error message, such as one saying the file being read has an incorrect format is much more useful, even if it was deduced (by your program) from the fact that an array was accessed out of bounds. But you can't just change the error message in the set method of the array, because it wouldn't make any sense - an array is used for many things and an out of bounds indexing attempt can mean many different things (depending on how the flow reached there). Only a method that's high enough in the calling hierarchy knows what each kind of exception actually means.

Second, letting the exception travel a few levels higher allows your program to reason better about the problem and possibly try another course of action, possibly without bothering the user at all.

Third, catching the exception and displaying an error message at such a low level doesn't let the caller method know that an exception has occurred at all. This means that the higher level logic of the program will continue its normal flow as if nothing had happened, thinking that every operation until now has been successful. This is a kind of wrong behavior and it can range from relatively harmless to destructive.

So, to answer your question, usually the correct (practical) approach for the specific example in your question would be simply

void setArray(int item, int index) {
    A[index] = item;
}

and you'd have to handle the exception at a higher level. If you want a general way of deciding what to do in those cases, read my answer here.

+1 Keep it clear and simple and don't invent error conditions are not unlikely to be handled correctly. — Peter Lawrey, Jan 21 '13 at 09:07

score 2 · Answer 2 · answered Jan 21 '13 at 07:59

2

ArrayIndexOutOfBoundsException is a runtime exception.

Throwing an IllegalArgumentException in the first code snippet which sanitizes the input makes more sense.

answered Jan 21 '13 at 07:59

Ajay George

11,759
1
40
48

Where have you read that runtime exceptions should not be caught? – aioobe Jan 21 '13 at 08:00
corrected. What I meant was that it wouldn't make a lot of sense to catch that RuntimeException and just log it. – Ajay George Jan 21 '13 at 08:03
From Effective java : There are two kinds of unchecked throwables: runtime exceptions and errors. They are identical in their behavior: both are throwables that needn’t, and generally *shouldn’t*, be caught. – Ajay George Jan 21 '13 at 11:07

score 1 · Answer 3 · answered Jan 21 '13 at 08:00

Exceptions, especially unchecked, are for exceptional cases. If you can predict the point of failure, validate the input yourself. The only exception for me is NumberFormatException, as this is obviously a hard one to validate yourself.

Unchecked exceptions are meant to be used where the API user probably can not recover, but you obviously can in this case.

Which is the style professional programmers use, using try and catch or adding the error handling in the code?

3 Answers3