Should a method ignore illegal input or raise an exception?

Question

If a method checks it's input and detects illegal input, what should it do: Raise an exception (or use another error-mechanism) or do nothing/ignoring on the wrong input?

In Java the HashTable-class throws an NullPointerException if given null-references as parameter. This is sometimes annoying, but I think it may have advantages, because errors are catched early. Some other methods ignore illegal input, doing nothing. That is less annoying and normally nothing bad is happen, but there might be cases, then this behaviour causes headaches - or not?

I'm not sure, which way is better. So I ask you: What do you think on this question?

Answer 1

Definitely throw an exception. Exceptions are annoying on purpose to force you to do something about them.

Think of it this way, if your program does nothing on bad input, how are you supposed to let the user know that nothing happened and why? Also, how long will it take you to debug a program that does nothing on error conditions?

Answer 2

This depends very much on the application that you're developing.

Soldiering on despite illegal inputs may mean that the output of the program is incorrect, which for an application that calculates medicine doses would be a very Bad Thing. On the other hand, if nothing catastrophic will result then doing nothing will probably be OK.

Another option is to change the illegal inputs to the closest legal value (e.g. if the range for an integer is 0 - 100, and you receive -10, it might be fine to set it to 0 and continue processing).

You should try to think about the possible consequences of how you handle errors in the particular method you're writing and how your error-handling will affect the overall application.

Answer 3

Assuming this is a public method, what is the contract between the method and those calling this method?

If you are writing this method, then the contract is part of the design. You can elect to

• flag the error in some fashion (a custom exception is one choice, but not the only one)
• correct the error in some cases and continue
• ditch the erroneous input and proceed as if nothing had happened.

In the end, it really depends on what the method is doing and what expectations you have of the method.

You could substitute Class for method and have the same options.

In some cases, you may not be able to raise an exception - i.e. firmware-embedded microcontrollers. In those cases you must have a process designed for handling erroneous input and continuing to process valid input.

Cheers,

-R

Answer 4

I think that it depends on the context or layer of abstraction you are working on. The most important thing is to be consistent. If you are throwing exceptions in that level, go ahead and throw your exception too. If not, check how the layer is behaving and do the same.

Answer 5

Fail Fast: Never ignore wrong input. You may hide problem and make them very hard to find.

Some push this very far with Design by Contract (DBC).

Follow the practices that are already used in your project or in your company - or define them now.