Java: Catching exception - unchecked vs.checked

Question

I have some code code splits a string (user input) into an array and passes the elements of that array into a method as arguments. If the array does not have enough elements an ArrayIndexOutOfBoundsException is thrown automatically. However, this is an unchecked exception, and since this is a problem with incorrect input from the user I could instead check for this condition beforehand and throw a checked exception.

So, I have a couple of questions:

1. Would it be better form to handle the unchecked exception or throw a checked one?
2. If I do throw a checked exception, should I use IllegalArgumentException? My understanding is that it is for illegal argument types, not an illegal number of arguments.

Thanks.

Answer 1

Checked exceptions are those which compiler forces you to deal with which is not the case with unchecked exception. Now as per your question you code should be written in a fashion so that no scenario arises so that unchecked exception is thrown(for example :- null pointerexception,ArrayIndexOutOfBoundsException).

If your code throws unchecked exception then there is issue in the code. As you pointed in your case that input data is not correct, then ideally you should do the validation on input whether its expected one or not and give error message, so there wont be any need to convert the unchecked exception to checked one

So in ideal world there is no need to convert the unchecked exception to checked one. Yes if there is specific scenario we can technically do that.

Answer 2

Would it be better form to handle the unchecked exception or throw a checked one?

It would be better to throw a checked exception indicating a problem with user input. Unchecked exceptions should be reserved to indicate programming problems from which you cannot recover without changing code; user input is not one of these problems.

If I do throw a checked exception, should I use IllegalArgumentException? My understanding is that it is for illegal argument types, not an illegal number of arguments.

If your design constraints allow you to use application-specific exceptions, design one for the case of invalid user input. This would make the code that uses your API look more explicit about the exceptions that it expects.

Answer 3

If you have a way to re-prompt the user for correct input, ie if there's a logical way to handle the exception, then do so. If you're expecting somebody farther up the call stack to handle the exception, then throw a checked exception. If you're just giving up, then let the unchecked exception go through (or repackage it in a more informative RuntimeException for the benefit of whatever logger is eventually going to catch it). This is general advice for all exceptions. (Additionally, don't log an exception and re-throw it - either log it or re-throw it, not both.)

Answer 4

Would it be better form to handle the unchecked exception or throw a checked one?

最好在尝试处理输入之前验证输入，并要求用户再次尝试输入它是否无效。

Answer 5

Basically when you decided to deal with Runtime exception, in your case, ArrayIndexBoundofExcepgtion, you are likely to proceed further without an abrupt interruption of the application.

So it is your business decison that what to do or not if your array is not having enough data.If it really affects the business data flow, it is better to deal with a checked exception so that you can sanitize your input data.

Answer 6

Would it be better form to handle the unchecked exception or throw a checked one?

Throw an unchecked exception. You can always catch a RuntimeException and march on. Then again I'm biased towards unchecked exceptions since I dislike all checked exceptions.

If I do throw a checked exception, should I use IllegalArgumentException?

Yes it should do going by the javadoc quote below. You can create your own checked exception if you want to convey something more specific. It depends on your design.

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

Answer 7

I suggest avoiding checked exceptions. See the following for some backing arguments:

• Checked Exceptions Might Have Their Place, But It Isn't In Java
• why hibernate changed HibernateException to RuntimeException (unchecked)

Whether you define your own class extending RuntimeException and throw that or simply allow the ArrayIndexOutOfBoundsException to be thrown depends on the context. Generally, the later is sufficient.