CODEWITHSUNDEEP
.neterror-handling
Sean Taylor
Sean Taylor

Reputation: 5028

What are the best practices for returning errors from functions?

I usually do something like the example below when I need to return error messages from a function, if no errors occur I just return an empyty string. Is this best practice, or are there alternatve ways of returning error messages from functions?

Function Test() as String
  ' Do something
  If error occured Then   
    Return "Some error message"
  Else   
    Return ""    
End Functon

Upvotes: 1

Views: 1610

Answers (5)

DavGarcia
DavGarcia

Reputation: 18792

A Request-Response pattern can help with handling errors and the many ways something might fail. For example, in a credit card authentication procedure you might have:

class CreditCardAuthenticationRequest {
    string CreditCardNumber;
    string FullName;
    ...
}

class CreditCardAuthenticationResponse {
    CreditProcessorStatusCode Status;
    CreditProcessorWarnings[] Warnings;
    CreditProcessorErrors[] Errors;
    Exception Exception;
    ...
}

Now suddenly all your error handling and validation can be contained in a neat little package. The Patterns in Action sample application from DoFactory.com uses this extensively.

Upvotes: 1

Jon Skeet
Jon Skeet

Reputation: 1500785

As Erik and Bill have said, exceptions are the normal way of propagating errors in .NET. However, there are situations where they're not appropriate - such as validating user input. At that point there are a couple of alternatives:

  • Use an error code (e.g. an enum) to indicate the type of mistake. For instance, you might have one code for "Password was too short" and another for "Password didn't contain any numbers" etc.

  • Use an error message in the way that you've suggested in the question. I would personally use a null reference for the "it was okay" case or possibly make the method return a Boolean value (valid/invalid) and have an out parameter for the error message. Using a string is lousy for internationalisation, but is simpler in many ways (avoids extra lookups, easier to add a new kind of error etc) than the error code version. That may well be fine for an internal app which will never need to be internationalised.

I stress that these are only options where exceptions don't make sense - otherwise, exceptions are the way to go.

Upvotes: 5

Bill the Lizard
Bill the Lizard

Reputation: 405775

Exception Handling is the preferred method for dealing with errors. Error code return values can be obliviously ignored by developers using your functions. Exceptions force them to take notice. It's definitely worth learning about.

When you wrote the code in your question, you probably assumed that it would be called like this:

String message = Test();
// process the message for errors.

A lot of developers will just bypass processing the message, or even call your function like this:

Test();
// go about your business, happily ignoring the error message

If your code throws an exception instead, it cannot be ignored. A developer has to at least acknowledge that an exception is thrown by putting a try block around your function call. At that point they're forced to do something with it.

Upvotes: 6

tvanfosson
tvanfosson

Reputation: 532475

I would agree that, in general, you would want to use exceptions for errors when the method would not otherwise return a value. If the method does return a value, however, you can and perhaps should use the return value in certain circumstances. For example, if you are attempting to retrieve an object from a keyed collection and the key doesn't exist, it's perfectly reasonable to return null as evidence of non-existence rather than throwing an exception. Your case doesn't seem to fit this scenario, however, and I would go with the exception.

Upvotes: 0

Erik Engbrecht
Erik Engbrecht

Reputation: 3164

Instead of returning an error message you should throw an exception that contains the error message.

Here's a quick overview: http://www.vbdotnetheaven.com/UploadFile/rajeshvs/dotnetException04162005022135AM/dotnetException.aspx

Upvotes: 9

Related Questions