Should I catch this NumberFormatException in a method?

Assumption that I have method like

void A(long input) {

  ......

}

Basically, it works well when the input is long or could succeed convert other types to long.

But, when some wrong data inputs, there will throw NumberFormatException. So a robust method should be

void A(long input){

   try{
       ...
   }catch(NumberFormatException e){

   }

} 

However, some developers argue that the project is a BS application. So the input is passed from the web ui. So it could confirm the input is valid. And no needs开发者_Go百科 to handle this exception.

But I think it is a must. What do you think? Thanks.

If the method accepts a long, then there's no conversion within the method itself -- the argument will be converted as it's pushed onto the stack, before the method is called, and you won't be able to catch the conversion error within the method itself.

If you want to pass a String that has the argument, then you'd be doing your own conversion -- and would either need to catch the exception or let it be thrown. Either way can be equally valid, and the choice depends on how you want to handle invalid values. If you're just going to be throwing an exception that says "this isn't really a number" or something, then you may as well just let the exception be thrown.

Whether or not to catch exceptions inside a function is really a choice. The function specification helps.

In your case, however, since the function does not return anything, how is the caller meant to know that something wrong happened? If it does not matter, then catching may be fine. If it does matter, then propagating the exception is a good way of notifying about the error's existence (unless the function signature is changed).

I think it's better to have a try-catch block that is never used than not having one and need it. The fact that the input is passed to the Web-UI means that any validation logic can be modified in the future.

However, what you need to do is to make sure that the user is notified of the error.

Sometimes, we are 99.5% sure that an exceptional condition can't occur in a piece of code. But if the remaining 0.5% can harm the application or database consistency, it might be better to catch an exception and throw a runtime exception before bad things happen:

private void String(String validatedStringWithALongValue) {
  try {
     long l = Long.parseLong(validatedStringWithALongValue);
     // ... do what has to be done
  } catch (NumberFormatException oops) {
     Exception e = new RuntimeException(oops);
     log.error("Bad news - validation failed or has been bypassed", e);
     throw e;
  }
}

The answer to this question depends on your system design.

• If it is the responsibility of the Web UI to perform data type validation, then it is reasonable for the next level to assume that validation has been done, and allow the NumberFormatException to propagate. However, at some point though, the server side code should catch the (unexpected) exception, log it, and produce an appropriate HTTP response code.

• If it is not the responsibility of the Web UI to perform data type validation, then the next level needs to generate a suitable (user friendly) error message, and make it easy for the user to correct it. (For instance, a web UI implemented in HTML only won't be able to validate data to any degree.)

If your system design does not clearly specify where responsibility for the various kinds of validation belongs, then the design is flawed.

You should also consider whether it is a good idea to pass numbers as strings after they have been validated. This may be necessary; e.g. if the layers are in separate webapp containers. But if the validation and business logic are in the same servlet, then the former should be passing an int or long and not a String representation of a number to the latter.

Finally, if any of the notionally internal web apis are in fact exposed, you should at least do enough validation to protect them against hacking. For instance, if the user-facing Web UI is HTML + Javascript, then there must also be an exposed HTTP-based API that it communicates with. It is a simple matter for a hacker to circumvent your GUI and talk directory to the HTTP API. So the HTTP API should validate requests at least to the extent necessary to foil attempted exploits.