Is it good practice to use try catch for data validation [duplicate]

Question

In my current development task, I want to validate whether a string is in JSON format or not. When I checked for solutions from resources like StackOverflow I saw many of answers are as below,

try{
   JsonParser parser = new JsonParser();
   parser.parse(passed_json_string);
} 
catch(JsonSyntaxException jse){
  System.out.println("Not a valid Json String:"+jse.getMessage());
}

According to my knowledge, we are using try-catch to avoid terminating the program from exceptions.

According to the above solutions, I feel like I'm going to generate exceptions and from that and then validate my string.

Furthermore, the program pseudocode below is better than using a try-catch block,

if(string is JSON){
 // do this
}else{

// do this

}

Based on comments

Actually, my question is like this

Let's assume there is a zero divide problem

if(input > 0){
 result = number/input
}else{
print("inplut not valid")
}

or

try{
 result = number/input
}catch(){
print("input is not valid")
}

my question: which one is good practice?

please correct me if I'm wrong. thanks in advance

Answer 1

The problem here is most probably that your JsonParser does neither have a method isJson, nor does it have a method tryParse (which could avoid the duplicate work which would be involved in first testing for "parsability", and then parse again to get the actual result). So I guess you have no other option than catching the exception. But that's not "wrong" or "bad". Assumed getting a non-valid Json string is an "exceptional" situation (and not the regular case) this looks pretty natural.

In case your JsonParser would provide a tryParse method, it might be a good idea to use it instead of try/catch, since the resulting code would be a little bit shorter. However, to some degree this is still a matter of taste.

One issue with your second example is that in certain programming languages for certain numeric types a "division-by-zero" does not necessarily throw an exception. Some languages have a number representation "Infinity", at least for floating point math.

But let's assume this to be a case where an exception would be thrown, and input be an integer value, not a floating point. Then we see another issue here: the test if(input > 0) is not semantically equivalent to the implicit test done in the try/catch variant (which is if(input != 0)). So the if/else construct allows you to place a different, more strict validation into a single line. If that's what you want or need, the if/else is obviously the more correct choice.

Another thing might be performance: in lots of languages throwing an exception might be more costly than making an explicit test beforehand. However, in cases where a zero denominator occurs seldom, this might be negligible. So in case

• you want a test for the denominator to be unequal to zero

• the performance hit of the exception is negligible

it boils down to a matter of taste which construct to use. Note the try/catch might be beneficial in cases where the numerical calculations are more complex and you would have to check more than just one denominator, or multiple lines for validity (assumed you don't want individual treatment for different error situations).

So in short: there is no braindead "one size fits all solution", you have to look at the real individual case, the language, the provided features, the specific requirement, and not at some sloppily written pseudo-code out of context. Make yourself aware of the semantical differences and the performance differences, and then decide which elements to use.

See also: Arguments for or against using Try/Catch as logical operators

Answer 2

If testing for proper input is simple, e.g. "is the input string non-null and non-empty", you should generally test the input.

If testing for proper input is difficult, then try / catch is perfectly fine. Imagine writing a regular expression for proper JSON. I think it's impossible - some Comp Sci Ph.D. could explain. Testing for a valid number that might be in scientific notation? Or a possible Date and Time? That is possible, but still a lot of work.

When testing for proper input format is this difficult, don't spend your time and effort on possibly buggy validation code - just try to parse it, with robust, well documented, and tested library code. And then deal with any thrown errors.

The question of where the catch should be is always challenging. It depends. But, unlike your (I know, contrived) code, the catch should almost never just print (or log) something and continue.

Answer 3

It's not a great use of try catch.

If you are using exceptions you want to allow them to bubble up to the top layer of the program, where you can handle them in a generic handler to output an error message or log.

ie

MyProgram
{
    Run()
    {
       try
       {
          //program loop
       }
       catch(e)
       {
          console.WriteLine("Error: " + e.Message);
       }
    }
}

For validation you really want to have a boolean function to call.

bool ValidateJson(string json);

or better yet a list of errors

List<ValidationError> ValidateJson(string json);

so you can do conditional logic

   if(ValidateJson(json))
   {
       //parse json and do stuff
   }
   else
   {
       //prompt user to fix json rather than erroring the entire program
   }

Obviously you can use try catch for conditional logic, but its less efficient and not as nice.