Question

I am working on application where user invokes a method from UI , on this I am calling a method from business class which calls another methods

UI–> Method1 –>Method2 –> Method3

I want to display the error message to user if any exception occurs in any of the method.

Shall I go with throwing the exception directly to the caller method and at the UI layer I will catch exception and display the message.

Apart from Throwing exceptions and catching it at caller is there any better way to handle it?

I do not want to use the C++ convention where integer is returned as the result.

Answer 1

Given your example of UI–> Method1 –>Method2 –> Method3, I would make sure that the UI has a try/catch, but then none of the other methods should catch exceptions unless they can handle them without re-throwing. And even if they handle the exception, you should question whether that exception should happen in the first place. If you handle an exception and go about your merry way, then that exception is part of your normal process flow which is a serious code smell.

Here are my recommendations:

1) Put your exception handling code in all your UI events, and then have the actual action farmed off to some other method. Don’t scatter exception handling code all over the place. It’s clunky and makes the code hard to read.

protected void Button1_Click(object sender, EventArgs e) {
   try {
      DoSomething();
   }
   catch Exception e {
      HandleError(e);
   }
}

2) Don’t do this. You’ll lose your stack trace and the next developer who maintains your code will hunt you down.

try {
   DoSomething();
}
catch Exception e {
   throw e; // don't rethrow!!!
}

If you aren’t going to handle the exception, don’t catch it. Or, use a naked throw like this:

try {
   DoSomething();
}
catch SomeException e {
   HandleException(e);
}
catch {
   throw ; // keep my stack trace.
}

3) Only throw exceptions in exceptional circumstances. Don’t have try/catch blocks as part of your normal process flow.

4) If you’re going to throw an exception, don’t ever throw a System.Exception. Derive an exception object and throw it. I often just a generic BusinessException class. This way, users of your code can determine what exceptions you made up and which ones are system/environment related.

5) Throw ArgumentException, ArgumentNullException, or ArgumentOutOfRangeException if a method caller violates the contract (preconditions) of your method. If you catch one of these, it’s a programming bug. A user should never see these exceptions.

If you remember that exceptions should be a very rare occurrence and that handling them is almost always a UI concern (so the bulk of your try/catch code should stay at the UI level) you will do well.