自定义流可以引发自己的自定义异常，还是仅应引发IOException？

Question

I have my own Connection class and a ConnectionStream class which essentially just wraps the Connection's send/receive methods.

The Connection send/receive methods can throw exceptions like ServerClosedConnException or NetworkShutdownException

Should my Stream be catching these and wrapping them in IOException (using innerException), or can it just let them bubble up to the user (with some try-finally to handle cleanup ofcourse)

I see in the .NET framework, the NetworkStream wraps any errors from the Socket in an IOException

Answer 1

Don't catch exceptions unless you intend to handle them. They will bubble up the call stack until an upstream handler catches and handles them, or the program terminates.

If your Connection class is throwing a very specific exception like ServerClosedConnException or NetworkShutdownException , and you catch that and rethrow a less specific IOException , I don't see how that is adding any value.

Answer 2

The best practice is to let exceptions bubble up unless you have more details to add or you can handle the exception yourself. In the first case your throw a new exception with the actual exception as the InnerException .

Read Wrapping Exceptions in MSDN.

In your case I would let it just bubble up.

Answer 3

The Stream base class acts as the defacto contract for its subclasses. If you are planning on exposing your subclass in a public API, it would be considerate to abide by the documented behaviour for the Stream class, since the user of your subclass might be blissfully unaware of its particular type. For example, if you wish to abide by the contract of the Read method, your implementation shouldn't be exposing any exceptions that aren't of a type listed at http://msdn.microsoft.com/en-us/library/system.io.stream.read .

However, this doesn't mean that you can't use more specific exception types. If you have reason to create a custom exception type anyway (assuming you think this is a good idea after reading the design guidelines mentioned by JerKimball), it could potentially be a subclass of IOException. However, this probably shouldn't be necessary unless users of your Stream subclass are likely to want to do something besides logging with the exception details.

Answer 4

Here's what the Exception Guidelines say:

[ref]

• Designing Custom Exceptions
• Choosing the Right Type of Exception to Throw
• Design Guidelines for Exceptions

The most relevant portion:

Do throw the most specific (the most derived) exception that is appropriate. 
For example, if a method receives a null (Nothing in Visual Basic) argument, 
it should throw System.ArgumentNullException instead of its base type 
System.ArgumentException.

I would extrapolate that to also mean in your case, the most detailed exception is the "correct" one to propogate; making a few assumptions about your exception types, they are probably the "correct" one to propogate, possibly wrapped in a "ConnectionException" custom exception.

That said, I do see how it would "make sense" to consider wrapping it in an IOException , since that is the "shape" of the exception; but in cases where I disagree with the guidelines and I go my way, it usually bites me later down the road. :)