1

How important it is (in programming languages in generally actually) the exact type of exception type? Say I have a hierarchy of chapters of a book, and I use a method to access the chapters. One would be:

public void chapterSearch(int chapter) {
    try {
    chapterString = this.hierarchy.get(chapter).getText();
    } catch(IndexOutOfBoundsException e) {
    throw new....
        }
}

The second is this:

public void chapterSearch(String chapterString) {
    for(int i = 0; i < this.hierarchy.size(); i++) {
    if(chapterString.equals(this.hierarchy.get(i).getText())) {
        break;
    } else if(i == this.hierarchy.size() - 1) {
        throw new IllegalArgumentException...
        }
    }
}

In the first method, it is obvious throw a new IndexOutOfBoundsException. But then there is the IllegalArgumentException which you can use, which according to the javadoc is

Thrown to indicate that a method has been passed an illegal or inappropriate argument.

which seems quite appropriate for the situation, too. I mean, passing a very large chapter number where there is no such chapter number seems quite inappropriate to me. Or, as in the comments, I can throw my own new Exception, ChapterNotFoundException. But this might be cumbersome, and I might not be using this Exception more than once -- it might then seem that using a pre-existing Exception is more apt.

But in general, even if in this case IndexOutOfBoundsException remains most appropriate, or if you would prefer, ChapterNotFoundException, how much does the choice of exception type matter in general?

I guess creating your own Exception type makes loads of sense once you use it a lot, but what if you aren't?

Edit: A good, related answer, though the answer below is very good as well, is here.

Community
  • 1
  • 1
Soyuz
  • 1,077
  • 1
  • 8
  • 16
  • why not a custom ChapterNotFoundException ? – BigMike Feb 18 '13 at 08:08
  • Sure. But the real question I wanted to ask is where's the line you draw between creating your own new exception type, using an existing exception type, or just throwing a general exception a la 'throw new Exception("error");'. And whether or not this all really matters that much. – Soyuz Feb 18 '13 at 08:09
  • 1
    Check out this [question](http://stackoverflow.com/questions/77127/when-to-throw-an-exception). Its answered here already. – Rahul Feb 18 '13 at 08:14
  • Thanks a lot. Didn't seem to find that one. Should I delete this question? – Soyuz Feb 18 '13 at 08:15
  • Yep. If you've got your answer. – Rahul Feb 18 '13 at 08:16
  • In my opinion (but that is really personal) it is more a matter of style and clarity. Choosing the appropriate exception makes your code more readable and thus more maintainable, both for you and then for others in case more people are working on the same project. There are several books about code readability, one I can suggest is "Implementation Pattern" by Kent Beck (I read it, it is not really technical but gives a good flavour and some solutions to the problem) – ThanksForAllTheFish Feb 18 '13 at 08:18
  • Reading your code you prefer a criptyc throws ArrayIndexOutOfBoundsException or a speaking "ChapterNotFoundException" ? I ask myself this question each time I have the doubt. – BigMike Feb 18 '13 at 08:26
  • of course if that piece of code isn't going anywhere except your project throwing a custom exception is less significant. – BigMike Feb 18 '13 at 08:28

2 Answers2

3

I think it depends on how you want to handle the exception. If you want the program to fail then later dig into the log, I would vote for

throw new IllegalArgumentException("Unexpected chapter: \"" + chapterString + "\"");

If you want to catch the exception and deal with it, then creating a ChapterNotFoundException makes more sense. However, if you want to deal with it in your code, you should think about creating a boolean method that checks if the chapter exists, and avoid handling the exception at all.

Bob Wang
  • 606
  • 4
  • 8
2

By Good coding guidelines it is very important to capture the exact exceptions (as far as possible) .

Reasons as below

  1. There are situation when you need to handle exception and do some repair work in case of exceptions. The repair work that you do could be different in case of different exceptions and there can't be a generic way of handling it. So in these situation you can handle specific cases in appropriate catch blocks of the exceptions.
  2. Second reason being, if some body is trying to invoke your method, if they know a set of exceptions that could possible be thrown then it's helpful for 3rd part who is going to re-use your method. If you simply throw "Exception" or "Throwable" , then it becomes too generic under the sky to handle it.

To say it in a line, it's always better to answer to the point than beating around the bush

Vinod Jayachandran
  • 3,726
  • 8
  • 51
  • 88