3

The question is if it is prefered to Throw an exception or to prevent it from ever occurring. It is for a game project.

IndexOutOfBoundsException vs. coding around it.

I have a List<E>

private Attribute<List> attributes;

A method to get an item by index.

public Attribute getAttribute (int index) {
    if (index < 0 || index >= attributes.size())
        index = 0;

    return attributes.get(index);
}

In this case I am defaulting to the 1st element of the list.

Emz
  • 1,280
  • 1
  • 14
  • 29
  • 1
    Imagine you as user, playing the game, choosing an option and then this odd message appears saying: `IndexOutOfBoundsException when choosing weapon. Please report to game admins.` I won't play such game **ever**. – Luiggi Mendoza Nov 26 '14 at 19:22
  • That was my initial thought. I hesitated because it feels as if I've done something very wrong when I put myself in this situation were it can happen. – Emz Nov 26 '14 at 19:23
  • If you write that method and know that it can throw this exception under this specific circumstances, why would you write code that uses this method the wrong way? The user will dislike your game as much if it suddenly misbehaves by ignoring errors. And errors are your #1 way of finding bugs. Passing an index that is out of bounds is clearly a bug. – zapl Nov 26 '14 at 19:25
  • 2
    @LuiggiMendoza that does not mean that no exception should be thrown, it means that the calling code should be written in such a way that the index is always a valid value. – assylias Nov 26 '14 at 19:27
  • In a game, when an exception happens this means a **crash**. No one wants to be in a game when suddenly it says *game stopped unexpectedly*. You have to make sure you pass a valid index, everything else would mean you don't know what's going on in your code, it's not like this input is something you get from outside your application. – A4L Nov 26 '14 at 19:29
  • Even if you throw an exception in one area you can handle that thrown exception in the calling part of the code...there is nothing wrong with throwing the exception you should just handle the thrown exception from the calling code...lets say an index throws outofboundsexception for whatever reason just make sure you handle this exception in a graceful way – brso05 Nov 26 '14 at 19:31
  • 6
    If it's possible for `getAttribute` to be called with an `index` that's NOT between 0 and `attributes.size()`, then you have a bug somewhere else in your code that you need to find and fix. Debating whether or not to throw an exception here is a bit pointless. – Dawood ibn Kareem Nov 26 '14 at 19:33
  • @DavidWallace, as I wrote above. I haven't gotten to a place where I actually call it yet. I just reacted to it. – Emz Nov 26 '14 at 19:34
  • Then throwing an exception is exactly what you want to do. Hopefully, you'd never release code to the outside world, where the exception can still be shown to the user. But that exception will help you when you come to write whatever code calls this; because it will show you your mistake, instead of hiding it. So the answers provided by assylias and rgettman are correct in this case. – Dawood ibn Kareem Nov 26 '14 at 19:52

3 Answers3

8

Failing fast is generally a good idea: if an index of -1 is passed to that method, it probably means that there is a bug in the code calling the method. If you silently use index = 0 instead, (a) the calling code may not receive the expected result and (b) you may not notice the bug until it has become quite a mess to fix.

So I would simply use:

public Attribute getAttribute (int index) {
    return attributes.get(index);
}

which will throw an exception if required. If the code calling this method is bug free, that exception should never be thrown.

assylias
  • 321,522
  • 82
  • 660
  • 783
  • Would a debug output guard me against it you think? As @Luiggi mentioned it can be a bit pain as a player to experience that kind of error. – Emz Nov 26 '14 at 19:25
  • @Emz if you want to get an Attribute by index, it probably means that you know how many are availble so what Luiggi mentions should not happen. If you gave more context we could be more specific. – assylias Nov 26 '14 at 19:26
  • I don't currently have more context sadly. Taking a course in Java at the moment were they mentioned it being important to always take care of worst case scenario. (This project has nothing directly to do with the course.) – Emz Nov 26 '14 at 19:28
  • 1
    Either way will work fine, but with what @assylias showed, allowing the `Exception` to be thrown will save your life and hair as a programmer when debugging. Coding around all possible exceptions can be far more time consuming also. – Drew Kennedy Nov 26 '14 at 19:31
4

In this case, pretending that an index exists and is the same element as the first element is confusing and can lead to subtle bugs.

Here I would throw an IndexOutOfBoundsException if the index is out of range. Note that other code that calls this must be prepared to catch this exception and handle it appropriately.

rgettman
  • 176,041
  • 30
  • 275
  • 357
1

The answer is highly situational. In general, you want to handle exceptions elegantly whenever possible. That is, try to resolve / ignore them where you can. An IndexOutOfBoundsException is very often an example of where this is not possible.

Hard breaks because of exceptions is a last-resort. Do this only when your program cannot continue.

This question's answer has a good post on it. When to throw an exception?

Community
  • 1
  • 1
Bryan Davis
  • 134
  • 6