This is the very worst kind of Exception "swallowing".
try
{
. . .
catch (Exception e)
{
// Do nothing useful
}
The calling code knows that the function failed - it returned false - but can do nothing whatever about that failure.
If it had been thrown an Exception, it might have been able to take some more useful, corrective action. That's how Structured Exception Handling is supposed to work.
But throwing an Exception for each and every Validation error is expensive.
You know that the function failed - it returned false, which made the application behave a certain way - but have no idea why it did so and, therefore, no idea how to go about fixing it!
You should, at the very least, capture and record the Exception rather than making it "magically" disappear.
Another way could have been to return a string and treat empty string as validated, but I don't see that much cleaner.
Actually, it is and it's a very common model in Validation.
You ask your method to validate something and it returns you a message indicating what, if anything, is wrong with it. That's a far more "useful" value than just "Yes or No".
Validate
returns false? Will this be a program error?Validate
should never return false, and when it would, it would be a program error, yes? If that's correct, you could simply makeValidate
a void function.Task<(bool, string)>
. As before, when false, the string contains the error message.Task<string>
, with the convention of using null or the empty string if no error occured.