nicely exception handling

In our app, we use components developed by other teams. The question was how can I define a nicely way of exception handling than this

   try
   {
    someComponent.DoStuff();
   }

   catch (Exception ex)
   {
    textLabel= ex.Message;
   }

The component has no custom exception type, maybe a nicely way to do it would be to define a component specific Exception type and wrap this somehow? I know the question is very basic, but I am interested more in the let's say how it开发者_JS百科 is good to do it. If you call another component with no custom defined exception types, how do you handle any potential exceptions in an elegant way?

Ideally you would have the component development team do this for you - how else do they expect their clients to recognize and handle errors from their component? Scoping the exceptions that a component can raise is a fundamental part of good C# design.

If that's not an option, then implementing your own wrapper on top of the component to taxonomize its failure cases sounds like a good second best, and very noble of you into the bargain.

If the third-party library is poorly documented (they don't specify the exceptions that can be thrown by each method), there are tools available that can Reflect into the code and determine the possible Exceptions that may be thrown. This can get a bit daunting (there are a surprising number of exceptions that can be thrown for any given call), but it's better in principle than catching the general Exception type. Here is one commercial product that performs this type of analysis.

When you catch an error you are able to repackage it and then throw another error, at the most basic level you may just be adding more data - but, from what you've suggested, you could also replace the generic error with a custom error that, whilst it won't overcome the limitations of the response you've got from the component, would give the code further up the call stack the opportunity to respond more appropriately.

So in terms of just adding information in the most basic manner - by throwing a new exception with some additional text whilst still passing the original exception:

catch (Exception ex)
{
    throw new Exception("This is more about where the exception occurred", ex);
}

Now, if you want to define your own custom component exception you change the new Exception to new ComponentSpecificException adding data as necessary to the constructor but never forgetting to set the inner exception. Exceptions also have a data collection of key, value pairs into which you can insert more information (by creating the exception, adding the data and then doing the throw).

That's all fairly generic - working forward from there, where you can't necessarily anticipate all the exceptions you have to handle you don't try - you set up logging so that you know when you've got a generic exception i.e. one that hits the final catch - and then over time add exception specific catches above the generic to provide more appropriate responses or, at the very least, package up the error into less general custom exceptions.

Not sure I've explained that very well - but the notion is that as its difficult to anticipate every possible error you want to have a strategy to develop your application in a systematic fashion as you discover new exceptions.

Assuming you want to catch every type of exception, this solution looks fine to me.

Either from your knowledge of using the component, or by using something like Reflector to analyze the compiled component, what possible exceptions can this component throw? Would providing exception handlers for these allow you to provide better feedback to you users?

The only reasonable (much less "elegant") way to handle exceptions is to log them if you can't recover from them.

Then notify the user there was a problem and offer them the chance to try again (if it's an interactive program).

If your application is exclusively for .NET developers, go ahead and show them the exception message (though Exception.ToString is better, since it includes a stack trace). Otherwise, don't display exception messages in your user interface - that's a security hole and will only confuse your users.