开发者

How to distinguish different plain exceptions?

开发者 https://www.devze.com 2023-02-12 08:22 出处:网络
If I don\'t want to create custom-exceptions, then how to distinguish them when catching ? if (somethingIsWrong)

If I don't want to create custom-exceptions, then how to distinguish them when catching ?

if (somethingIsWrong)
   throw new Exception("Something is wrong.");
else if (anotherthingIsWrong)
   throw new Exception("Anotherthing is wrong.");
else
   throw Exception("Nothing is wrong!");

// Now when catching them:

catch (Exception ex)
{
   if (ex.Message.Contains("Something"))
      ShowUserErrorThatSomethinIsWrong();
   else if (ex.Message.Contains("Another"))
      ShowUserErrorThatAnotherthinIsWrong();
   // ...
}

I wish if System.Exception had a ErrorNumber property for customizing exceptions this way:

if (somethingIsWrong)
   throw new Exception(1001, "Something is wrong.");

// And catching them this way:

if (ex.ErrorNumber = 1001)
   // ...

I know it's possible to extending MyExceptionClass from System.Exception but is there any better solution ?

T开发者_JAVA技巧his is related to my other question which you can find here.


Creating your own exception type is the solution here.

You could set the HResult on an exception and throw it that way - but it's a horrible thing to do.

The language has been designed to catch exceptions based on their type rather than by error codes.

Of course, if you have several similar exceptions with some extra information which could be of interest to code catching it, you can add that extra information into properties of your custom exception.


This is the exact case I would introduce custom exceptions. While you shouldn't create custom exceptions just because you can, if you have a case where there isn't a fitting framework exception or the name would be misleading, create a custom one!

Your proposed code would make it harder to distinguish between exceptions, the caller would have to make assumptions about your code. With custom exceptions, this wouldn't be the case.


Creating custom exceptions by extending System.Exception is THE way to go. Why dont you want to do that?

Advantages:

  • You could catch all your custom exceptions by class type (rather than using that ugly .contains)
  • You could add the ErrorNumber property you want to handle error after catching
  • It is the most clean, direct, elegant solution.

Any strong reason not to use this approach?


I would say it's best not to throw Exception objects, because they are too general. There are many classes that derive from Exception within the framework, it's usually the case that there's one that fits the scenario you're in. If not, then extend Exception with your own custom class.

For example, if you're validating parameters coming into a method and find one is null when it shouldn't be, throw an ArgumentNullException. If two things are trying to be done out of order, throw an InvalidOperationException. You can catch these exceptions individually:

try
{
}
catch (ArgumentNullException argException)
{
}
catch (InvalidOperationException opException)
{
}

You might find even this approach too general, but I would say that a high-level component (e.g. a UI) doesn't really need to know the exact details of what's gone wrong, just that "something" went wrong. For example, if something goes wrong with a database command, you might get a SqlException thrown. You can catch that, log some details, then throw a more general exception.


Well, you are "supposed" to create your own exceptions in .NET. The exception model works best that way.

If you really want to have an ErrorCode you can create your own Exception and use only that.

public class ErrorCodeException : Exception
{
    private readonly int _errorCode;
    public ErrorCodeException(int errorCode)
    {
        _errorCode = errorCode;
    }

    public ErrorCodeException(int errorCode, string message)
        : base(message)
    {
        _errorCode = errorCode;
    }

    public int ErrorCode { get { return _errorCode; } }
}

Edit
If you for debugging purposes want to find out exactly which of all of your Exceptions that was thrown it is much better to have a look at the stack trace instead of assigning a sequence number to each exception you may throw.

0

精彩评论

暂无评论...
验证码 换一张
取 消