I am currently preparing for an exam and am working on the following task:

I want to catch the "ArrayIndexOutOfBoundsException".

I have following classes:

class Util { // get the smallest number of the given array @SuppressWarnings("unused") public static int minimum(int[] values) { try { int min = values[0]; if (values == null) { throw new NullPointerException(); } if (values.length > 0) { for (int i = 1; i < values.length; i++) { if (values[i] < min) { min = values[i]; } } return min; } else { throw new ArrayIsEmptyException(); } } catch (NullPointerException e) { System.out.println("Das ist kein Array"); } catch (ArrayIsEmptyException e) { System.out.println("Das Array ist leer."); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } return 0; } 

and from the main:

public class UtilTest { // Testprogramm public static void main(String[] args) { System.out.println("Die kleinste Zahl ist: " + Util.minimum(new int[] { 1, 6, 4, 7, -3, 2 })); System.out.println("Die kleinste Zahl ist: " + Util.minimum(new int[0])); System.out.println(Util.minimum(null)); } } 

How can i catch the exception of this output:

System.out.println("Die kleinste Zahl ist: " + Util.minimum(new int[0])); 

Thanks for your help!

4

1 Answer

When an error occurs, code immediately jumps out.

In your code, you're doing things which would cause errors under certain conditions (such as if the array variable is pointing at nothing (is null), or if it is an empty array), and THEN you check for these conditions, which is pointless.

It's like crossing the road first, and THEN checking if there's a car coming. You're either already roadkill before you check for traffic, or if you've made it safely across the street, checking is now pointless.

So, switch it around.

Specifically, this code: int min = values[0];

Will throw a NullPointerException if values is null, and will throw an ArrayIndexOutOfBoundsException if values is an empty array.

More generally, this:

catch (Exception e) { e.printStackTrace(); } 

is incredibly bad code. For starters this means code will continue after the error and thus generally your log will be filled with tons of error messages even when 1 thing goes wrong, and more importantly, an exception contains 5 useful bits of information: Its type, its message, its stack trace, its causal chain, and the batch of suppressed exceptions attached to it.

That last one is usually not particularly interesting, but the other 4 are quite useful. You're tossing out 3 of the 4 useful things and printing only the stack trace. In addition to that, you're repeating code EVERYWHERE with this kind of style.

So don't.

Do not ever write code that catches an exception merely to log it or print it. Just.. don't catch it, let the top level exception handler (which prints ALL useful information and then closes the thread, which is a pretty good default) handle it. If it's a checked exception, add throws X to the method signature, where X is the checked exception. For example:

good code:

public void deleteFile(String fileName) throws IOException { Files.delete(Paths.get(fileName)); } 

bad code:

public void deleteFile(String fileName) { try { Files.delete(Paths.get(fileName)); } catch (IOException e) { System.err.println("Something went wrong deleting file!"); e.printStackTrace(); } } 

That second bit of code:

  1. prints useless info ('something went wrong', yeah I know that, I'm looking at an exception)
  2. uses bad style; exclamation marks are not useful in error messages.
  3. code silently continues, so any code that calls this method cannot tell the deletion failed to occur. Also likely more errors will follow
  4. throws away a ton of information; that IOException may have a message such as 'file is marked read-only' which you've now thrown out.
  5. is much longer

and that's just a sampling of what's wrong with it.

3

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy