Is returning true or throwing an exception good or bad code practice?

Question

I am focusing on learning better design and wondered if this code is good or an anti-pattern? The function Validate() returns true if the data is correct, else it will throw an exception with a message to display in a popup.

Another way could have been to return a string and treat empty string as validated, but I don't see that as much cleaner.

try
{
    if (await Validate(data))
    {
        //logic
        success = true
    }
}
catch (Exception e)
{
   message = e.Message;
   success = false;
}

return new GenericResponse(success, data, message);

Answer 1

Either returning true or throwing an exception is an unusual way of indicating success or failure. It's not an anti-pattern, but it's not good practice either. Until I read the description of what happens properly, my immediate thought was that you weren't handling Validate returning false. It therefore breaks the principle of least astonishment.

A better approach would be to use the try pattern, eg for a language that uses out parameters you might have something like:

bool TryValidate(SomeType data, out string failureMessage);

where the return value is true for success and false for failure. When false, failureMessage contains the reason it fails (and it's undefined when the return is true).

Depending on the language you are using, you could use a tuple or even an Either<bool, string> union to return the data. Whichever method is used though, the principle of the pattern is true/false with a message when false is returned.

Answer 2

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".