Question

What is the best way to handle a function that might occasional fail to evaluate, but even when it does fail does not require a halt of the parent routine, though sometimes might require an explanation to the user?

I have such a function, deep in my code, that returns a number. Codingwise, the simplest approach would be to make the function nullable, and return null when it can’t evaluate. That way the calling routine can continue while also knowing the function failed to return a number.

However, depending upon the circumstances, sometimes I want to display the reason for the fail to the user so they know what to fix. Obviously just returning null isn’t enough information. Should I be raising messages inside the function itself as it evaluates for anonymous listeners to catch, to be displayed if desired?
(For those rightfully pointing out that logic functions shouldn’t be responsible for creating user messages, I didn’t mean to imply the function generates the full text message, just somehow transmits the reason for the problem so that the UI could later parse that into a message)

The other option I suppose would be throw exceptions inside the function if it can’t evaluate, then catch and interpret to user messages if desired. However, as stated the inability to evaluate typically does not signify a halt to the routine, and now I’d have to put a Try…Catch block around the function call everytime I use it.

Answer 1

You can pass out parameter “string for example” to the function, so whenever the function failed, by returning false or null print the cause to the user. Just like what Microsoft do with TryParse.. but here we are getting the reason of the fail as well:

public bool TrySomeFunction(out string errorMessage) 
{
    try
    {
        //code that may cause exception

        return true;//operation completed successfully
    }
    catch (Exception exception)
    {
        errorMessage = exception.Message;
    }

    return false; 
}