什么是枚举的好替代品？

Question

I'm writing a web service that returns different types of errors.
Each method can return one of the three basic types of errors:
General , InvalidInput , or Non .
In addition to those three possible values, each method can have it's own errors (eg for SignIn method - InvalidPassword) - but each method can return only one error.
So for example the SignIn method will be able to return one of the following error types: General, InvalidInput, Non, InvalidPassword.
At first I thought of using enums, but I now think that the error types should implement inheritance because there are the basic three types, and each new method's error types inherit from that.. But I can't really think how. I thought of using a static class - but then it will only have one string static field - and inheritance is irrelevant again...
Another problem with enums is that what the web service's client will get eventually is a meaningless int (through json)

So my question is: What is a good way of conveying the idea that there are three basic possible values, and you can add to those to make a new type of errors?

Answer 1

It would be best if you reconsidered your interfaces.

It is by far better to use exceptions over error codes not only because it is so easy to forget about checking for an error code, but also because it is difficult to maintain them, keep them unique and meaningful.

John Saunders states in a similar thread:

[...] you should throw a SoapException . This will translate more or less directly into a SOAP Fault. A SOAP Fault is the appropriate way to indicate an error with a web service operation for the same reason that Exceptions are better than return status in a normal method - you don't have to check the return status at the point of the call.

Besides throwing a SoapException you may also throw arbitrary exceptions. ASP.NET will wrap these exceptions into a SoapException that gets passed to the client. The client can access the details of the exception in the inner exception of the SoapException .

For further explanations see also:

Handling and Throwing Exceptions in XML Web Services