I'm looking for the best method of handling errors in a c# winforms class that I have. The gist of the application is that it has a data analyzer that analyzes the data for statistics and other such stuff. However, I'm looking for the proper way of handling an ABORT.

For example, I have the class called Analyzer

```
namespace PHOEBE
{
    public class Analyzer
    {
        public Analyzer(){
            DoAnalysis();
            DoFurtherAnalysis();
        }

    public class DoAnalysis(){
        try{
            Convert.ToInt32("someNumber...."); //obviously fails..
        }
        catch{
          //ERROR OCCURRED, ABORT ALL ANALYSIS
            return;
        }
    }
}

```

Obviously, when DoAnalysis() is called, there will be an error that occurs. The catch block will catch the exception. However, when this catch occurs, it will return to the constructor and run DoFurtherAnalysis(). This is a problem. 

I know that you could do return values from each method where each value indicates a certain outcome (ie. 1 = success, 0 = fail). However, a lot of the methods I call, use return values already. I could also use a boolean that gets flagged when an error occurs and check that value before calling the next method from the constructor, but checking this value each time is annoying and repetitive. 

I was really hoping for some sort of like "abort mechanism" that I could use. Is there any other ways of working around this? Any interesting work-arounds for this? 

Assume this class is being called from a form.
['https://Stackoverflow.com/questions/9776878', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/821484/']
Just let the exception propagate up - you should only catch the exception if you can actually *handle* it. Exceptions *are* the "abort mechanism" in .NET. You're currently *swallowing* the signal that everything's gone wrong, and returning as if all were well.

Generally I find catching exceptions to be pretty rare - usually it's either at the top level (to stop a whole server from going down just because of one request) or in order to transform an exception of one kind into another in order to maintain appropriate abstractions.
Well, you've got several issues mixed up here. First, it looks like you do possibly-very expensive processing from your constructor. If that processing can throw, you really don't want to call it from your constructor becuase you don't even have the option of returning an error code.

Second, (and you'll read in many threads here,) how you handlee errors really depends on the application and expectation of your users. Some errors could be corrected by changes to inputs. Others might happen in the middle of the night if analysis takes a long time and you might want to continue with another analysis, logging this error.

So I think we're really going to punt back to you for more information about the above.