In our code base, I see a lot of code like this
var error = ValidatePhoneNumber(userId, phoneNumber);
//if validation fails, return error
if(!string.IsNullOrEmpty(error))
{
return error;
}
If I were writing this, I would have just had ValidatePhoneNumber(userId, phoneNumber) throw the error and call the method inside of a try/catch block. The only reason I can think of for this kind of practice is that throwing/catching errors can become expensive. Would concerns of performance really necessitate this kind of error handling? Or would a try/catch pattern be more useful in this situation?
I've seen posts like this, and I can see that there are some minor performance differences in including exceptions, but are they large enough to concern most applications?
(I work mostly in the .NET framework, if that makes any difference to the answer)
Is the phone number expected to be valid at this point, or is it an error that isn't
? There is not enough context at this point