C# Creating A Error Checking Class?

I'm very new to OOP, and in the program I'm working on, I have an Utilities class that contains some general methods. Should I include my error checking in the Utilities cl开发者_运维知识库ass or should I create a new class just for error checking?

---

"Utilities" classes tend have a nasty habit of becoming monstrosities -- keep the error checking code separate.

---

I don't know exactly what you want to do, but it is a safe bet that error checking class(es) should not be in your Utilities class. Error Handling is a class of functionality that warrents it's own class(es).

Also, remember OOP is not putting your functions and routines in classes. OOP is making classes that represent things. Avoid "Utilities" classes as much as possible.

---

Generally speaking, I either handle errors where I am writing the code, or let the caller handle errors (i.e. let exceptions pass up the call stack). It doesn't matter whether it is a utility function or not.

public static class Utility
{
    public static string GetSomeString(string someOtherString)
    {
        try 
        {
            // something
        }
        catch (exception ex) 
        {
            // handle error
        }
        return result;
    }
}

---

I think neither. Errors are usually Exceptions, which are classes themselfes and handled exactly on spot where you know how to deal with them.

If you're looking for logging or similar tasks, you should use a finished framework for that, such as Log4Net, or use AOP such as provided by PostSharp.

---

Error checking, such an input validation should go along with what needs to be checked - unless it's rather complex, in which case it should be moved to separate methods in the class of the thing being checked. If it's still too complex for that, a separate class that's devoted just to validation should be made. The validation class should be nested inside your main class, or it should be marked internal.

---

What about using the Application_Error event in the Global.asax file? This gets fired when any unhandled error occurs int he application.

---

There are different forms of error checking

If you mean error checking in the sense of validity id jsut do it in code ... when you find that you have common tests EG string has length, maybe a regex ... ints have a range ... i end up with a static class with these tests in however that is simply a refactoring. I end up with a static class with sub static classes to get to the methods ...

Unit testing

These would be in different project to the main code again simply to define to scope of methods.

Error Checking.

I tend to use debug.assert statements all over the shop for general error checking in my methods and functions to test assumptions whilst debugging - I tend to use these as a weak form of unit testing.

Exception Management

This depends on the area you are working in. Exceptions in the backend have very different management scenarios than the front end.

for iinstance WCF has a interface for exceptions. IErrorHandler iirc correctly, but as far as anything connecting to it there are just a few faults that can be fired accross. At the backend these faults could caused by exceptions that are many exceptions deep with data attached to them at all levels. You don't want that data to hit the front end - but you need to record it. As a result the exceptions at the front end are simply the husks of the real exceptions ... my point is that by the time you have sorted that out your utility class will be huge and you will want to start re factoring it into several classes.

But this is why exceptions need to be in a seperate project - you can then reference them from all over and reuse them.

I have a project that i tend to include for handling errors. I also have a WCF service set up that i can fire exceptions at in order to record them for if we ned them (think about targetted bug fixing).

An example of how things grow is that part of this requires being able to serialise the error and all its data.

So I would shy away from a single utility class ... things that start off as a single method generally grow at an alarming rate once scope creep starts.

This kind of goes beyond OOP into more architectural questions - you need to know why you want to move the code into a utilities class and ytou then need to decide if simply putting it there is enough ... I'd suggest that moving it out is good but you should go further and think of error management as an entire solution in its own right. Its begging for a SOA style solution (or at least project) imo .... its one of those things that is not only common accross applications but is also invariant ....