Returning Errors from a class (within a Class Library)

[pdpullmn612]

Hi guys,

I'm just trying to wrap my head around this. What is the best way to return error messages from methods of a class? For example lets say I have a method like this:

public class CustomClass
{
    public void PrintString(string mystring)
    {
        if(mystring == "Hello World!") // or some other way of determining if mystring is blank
        {
            // let user know that string cannot be "Hello World!"
        }

        // Do some other work with my string
    }
}

Now, lets say I want to display some sort of message stating that mystring cannot be "Hello World!" on a GUI application. Assuming that I'm referencing the library containing CustomClass, what would be the best way to do this? I know I could just throw an exception and then use try/catch block to display a message box, but is that necessary for input validation errors? I've read the just throwing a new exception can be consuming (in terms of application speed, performance, etc.) and that they should only be used in exceptional cases.

What would be the best way to just display a validation error to the UI from another class? Or, am I limited to only using exceptions? Thanks in advance for the help!

[pdpullmn612]

I just had a thought. Should I just be doing the checking within the GUI application itself? For example, I could have my method return a bool value. If mystring == "Hello World" return false. Then on the GUI side, say something like if(PrintString("Hello World!") { //display message box }

[sotoasty]

My Thoughts.

1. Don't put a message box in your class. That is for the GUI. What if at some point down the line, you want to use this same class in say a WCF service or Windows Service. You definitely do not want to have that there.

2. Have your function validate and set a property of the class ("Error Number"/"Error Description"). Then have the GUI display the errors or decide what to do from there. You could possibly even have a list of Error Objects and each time you call a function add the errors to the list. Then when all the Functions/Properties/Validations are done, display them all at once. You can even have a "Helper" class where you can put the form in that helper class that displays the errors. This allows you to pass in the Main class, and the helper class displays a custom box with all the errors. This has the benefit of having a central area for the code, with out cluttering your main class with GUI stuff.

[CGKevin]

My advice would be to stop thinking of input validation failures as errors. The terms "Error" and "Exception" should be reserved for conditions beyond the ability of the user to correct.

Input validation failures are correctable by the user. The problem is to get the message to the user that they have input something wrong (bad format, value, etc.) and that they need to correct it and resubmit.

[hspc]

Exceptions, not error codes should be used to communicate errors to callers in class libraries. you should not assume that the caller is a UI thread in a windows forms application, as long as your library is general purpose (and generally, it should be designed like that).

As Framework Design Guidelines recommends:

Do not return error codes. Exceptions are the primary means of reporting errors in frameworks.

and

Do report execution failures by throwing exceptions. If a member cannot successfully do what it is designed to do, that should be considered an execution failure and an exception should be thrown.

Regarding performance:

Consider the TryParse pattern for members that may throw exceptions in common scenarios to avoid performance problems related to exceptions.

But:

Do provide an exception-throwing member for each member using the TryParse pattern.

And remember that premature optimization is the source of all evil

@CGKevin:
I think ArgumentException should be used in these scenarios.

[CGKevin]

The first sentence in the document that you refered to states "Exceptions are thrown when a member cannot successfully do what it is designed to do. This is known as execution failure.". If you read the entire question, you will find that this is not what the poster is asking about (he is using the term "error" erroneoulsy). He is asking about user input validation. In addition to checking type, user input validation checks the input's content within a given context for validity.

Primarily, this type of validation is used to find all of the invalid user input data from a form, with the intent of reporting all of the things that the user must fix for a sucessful submission. If you use exception handling in this scenerio, the normal action for handling an exception is to immediately report the condition and halt execution until the condition is fixed. User's will find it frustrating if they have to fix a problem and resubmit, then fix another and resubmit, etc, until they get a sucessful submission.

I was suggesting a shift in the way he thinks about this sort of validation. An input validation failure is not an execution failure (which normally indicates something that needs to be fixed by the developer), but a failure of the user to provide input data that is correct not only in type, but content as well. Consider the case where the method requires a string for input, but with the following restrictions:

* The string can't be empty
* The string can't contain numeric digits

If a user submits the string "abc123", while still a string, the content is in violation of the second restriction. This is not, in the strictest sense, an execution failure. If the method is protyped to accept a string for this parameter, it will happily accept this string. Input validation, however should detect this as a failure and add it to the list of failures to report to the user to be fixed.

That being said, in the context of handling actual exceptions (execution failures), I agree with your post.

[hspc]

Primarily, this type of validation is used to find all of the invalid user input data from a form, with the intent of reporting all of the things that the user must fix for a sucessful submission. If you use exception handling in this scenerio, the normal action for handling an exception is to immediately report the condition and halt execution until the condition is fixed. User's will find it frustrating if they have to fix a problem and resubmit, then fix another and resubmit, etc, until they get a sucessful submission.

I agree that form submission validations should not be handeled using exceptions, the user should get feedback as soon as possbile, or be protected from entering invalid data in the first place.
But after passing this stage, the responsibilty shifts from the library client (the UI developer) to the library, which should protect itself from invalid input.
For examlpe, If you develop an FTP transfer library, if the client (caller) passses an invalid URI, then an exception should be thrown. But the client should make his validations in a user friendly way, if he has any kind of UI.