Choosing the Right Type of Exception to Throw

Why catch(Exception)/empty catch is bad

CLR Team Blog — Fri, 20 Feb 2009 01:42:59 GMT

You’ve seen the advice before— it’s not a good programming practice to catch System.Exception . Because

C#: throw; vs throw e;

nblog — Tue, 09 Oct 2007 23:12:29 GMT

Jakoś ostatnio często wpadają mi do rąk różne teksty o wyjątkach w .Net. Z tego co da się zauważyć, to

re: Choosing the Right Type of Exception to Throw

Sundar Rajan — Mon, 07 May 2007 14:02:15 GMT

Hi,

In your framework design book you mention that one should avoid throwing COMException since it is for the CLR to throw it.

We are in the process of writing a data access layer, which is in C#. However the first client of this layer is a COM/C++ application. In order to propagate exceptions from .Net to COM (so that the COM application gets a HResult) we are using COMException. Is this a resonable violation of the guideline, or is there a better way to communicate exception across interop boundaries?

Thanks

-Sundar

re: Choosing the Right Type of Exception to Throw

Krzysztof Cwalina — Tue, 05 Dec 2006 04:45:09 GMT

Nigel, I think the way to address the abstraction leak is to describe exceptions that can be handled in the contract of the abstraction. Having DataAccessTeamException does not help much: it's not an exception that can be handled, at least not more than System.Exception is.

John, yes, there are cases where we don't have a good general "it's a bug" exception in the framework, but such cases are extremly rare. In such cases, I would add a new exception, but I would not name it after the team; I would name it so it describes how it's different from existing exceptions in the framework (i.e. describe why you could not throw any of the existing ones). But as I said, it's extremly rare. For example, InvalidOperationException might be a good candidate in cases you described.

re: Choosing the Right Type of Exception to Throw

John Waterson — Mon, 27 Nov 2006 13:03:29 GMT

Krzysztof, thanks for this guidance, which is invaluable, but I've realised that there is at least one scenario where the guidelines contradict each other. That scenario is when an error condition arises that does NOT match any of the predefined system exceptions, but at the same time does NOT require any specific programmatic handling.

When would such a scenario occur? Well, for me it happens when I'm baking a fundamental, low-level assumption about an internal data structure into my code, and I cannot imagine any circumstances that would cause the assumption to be violated.

Now I'm acutely conscious that although I can't IMAGINE any troublesome circumstances, that does NOT mean that they don't exist. And quite often, the code path that would exist IF my assumption were violated is just staring me right in the face.

Equally often, Bad Things happen on that code path, and unless I'm in an absolutely performance-critical section, I don't feel good about just ignoring it. Obviously I can use Asserts to verify that it will never execute while I'm developing, but what if the assumption gets violated in a release build? My Asserts are useless. It seems negligent NOT to throw an exception, even though I'm pretty sure it will never actually be raised.

But I don't know how to handle that exception programatically. The circumstances that brought it about are, as I said, unimaginable and therefore by definition I don't know what to do in those circumstances. I just want my code to stop running before it wreaks havoc.

If I'm following the guidelines strictly then I can't throw Exception, SystemException or ApplicationException. But the assumption that's been violated is often unrelated to parameters or anything else I can articulate using the builtin fine-grained exceptions. Previously I might have created a NameOfMyProjectException and thrown that, just to indicate very clearly that, if the exception is ever raised, then it's a bug. But that's against the guidelines too.

Any thoughts on what to do in these circumstances?

re: Choosing the Right Type of Exception to Throw

Nigel Armstrong — Fri, 24 Nov 2006 17:01:09 GMT

I also think that you need to alter this exception story slightly. Specificially this item:

"Do not create and throw new exceptions just to have ‘your team's’ exception."

If you imagine having a typical multitier application, which has a UI that is going to use data by calling on a method from a data access class. You might have several data access classes (one for XML, one for databases, etc)...the XML reading and writing data access class might have to deal with XmlExceptions, the database one a SqlException. But it shouldn't propagate these back to the UI - instead in my view, your data acess team should create an exception class "the data access team's exception" - eg DataAccessException that is used for all of these classes to report back to the UI that an exception occured. Of course, this exception should set the InnerException correctly so that developers can drill down and see what they did wrong...if you don't do that, then you end up with an "abstraction leak" where the UI has to be aware of what the specific data access technology is being used at that time...

re: Choosing the Right Type of Exception to Throw

Krzysztof Cwalina — Sat, 07 Oct 2006 04:06:21 GMT

Krish, we are thinking about improving the current exceptions story. I agree that what we have today can be way better. We want to strike the right balance without being too rigid (checked exceptions) and too ad-hoc where as you note it's very difficult to write very robust code.

re: Choosing the Right Type of Exception to Throw

Krish — Fri, 29 Sep 2006 16:31:23 GMT

Hi Krzysztof, As described in more detail later, catching System.Exception is nearly always the wrong thing to do as well. I agree with you in principle, but the .NET mechanism of not being able to declare exceptions thrown by methods does lead to a lot of headaches. For example, if you properly document your code, you can ensure (not 100% safe) that many people are aware of the possible exceptions that can raised by the code you are calling into. If you don't document your code, well, too bad, and the only other options are to look at the source code (if available) or use ILDasm or some other tool to figure out possible exceptions that can be thrown by the code you're calling into. I'm not getting into a checked/unchecked exception debate here, but if a method CAN but does [not] have to declare the exceptions that it raises, [and] you add a compiler switch to raise a warning if not declared, that would help methods self-document themselves. Thoughts? -krish For example: // legal, but a special compiler flag could raise a warning public void M1(Boolean flag) { if (flag) throw new MyException1(); else throw new MyException2(); } // legal, but the special compiler flag could raise a warning for Exception2 public void M1(Boolean flag) throws Exception1 { if (flag) throw new MyException1(); else throw new MyException2(); } // legal, no warnings when using special compiler flag public void M1(Boolean flag) throws Exception1, Exception2 { if (flag) throw new MyException1(); else throw new MyException2(); } In theory, this is similar to Java exceptions that extend from java.lang.RuntimeException (an unchecked exception). Methods that raise the RuntimeException (or sub-classes thereof) can - but do not have to - declare exceptions in the method signature.

re: Choosing the Right Type of Exception to Throw

David Levine — Fri, 18 Aug 2006 05:03:25 GMT

I believe there are issues with using custom exceptions that need more guidelines.

When the exception thrown will be entirely consumed within the assembly that defines the custom exception then the guidelines above are sufficient (and then it really does not need to be marked as serializable unless explicitly serialized internally)

When the custom exception may be thrown across process boundaries, and especially across machine boundaries, then there are other factors that should be considered. The problem is that the entity that receives the exception must have a copy of the assembly that defines the exception to be able to deserialize the exception. If it does not have a copy of the assembly, or if it has the wrong version of the assembly, then a different exception will be thrown by the runtime when it attempts and fails to deserialize the custom exception. This is worse then not using a custom exception because the client will get a misleading exception type to deal with, and any extra data associated with the custom exception will be lost. The ability of an application to correctly interpret and respond to exceptions is of vital importance, and in this situation the abiity to deal meaningfully with custom exception type will be lost or degraded.

If this can happen then the custom exception should be mapped at the boundary of the source to an exception defined in a system assembly so that it can be easily consumed. (I feel this is such an important issue that the runtime should provide an automatic mapping service at the receiver to remove this burden from the sender, but that's a different issue).

In general, when custom exceptions are exposed to external clients across process and machine boundaries then consideration must be given to the deployment and versioning issues of the assembly in which the custom exception is defined, and if clients will have access to this assembly. If these issues cannot be adequately addressed then consider using standard exceptions instead.

Choosing the Right Type of Exception to Throw

Why catch(Exception)/empty catch is bad

C#: throw; vs throw e;

re: Choosing the Right Type of Exception to Throw

推薦一個很棒的 Design Blog. "Krzysztof Cwalina"

re: Choosing the Right Type of Exception to Throw

re: Choosing the Right Type of Exception to Throw

re: Choosing the Right Type of Exception to Throw

re: Choosing the Right Type of Exception to Throw

re: Choosing the Right Type of Exception to Throw

re: Choosing the Right Type of Exception to Throw