How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

Tom Kirby-Green — Wed, 31 Jan 2007 06:22:44 GMT

Great post Krzysztof, the whole subject of good design of exceptions keeps coming up at my shop. You latest post helps no end, many thanks! :-)

How to Design Exception Hierarchies

The Visual Studio Code Analysis Team Blog — Wed, 31 Jan 2007 08:17:15 GMT

Krzysztof Cwalina, owner of the Framework Design Guidelines , has written a great post on How to Design

re: How to Design Exception Hierarchies

Thanuja — Wed, 31 Jan 2007 14:41:53 GMT

Thanks KC for the post.

I would like to know ur idea on following design. Think we have several framework components that fall in to several assemblies such as Caching, Data Access Framework, Configuration, etc. Then we create separate exception classes derived from System.Exception and place in each of the component, such as CachingException, DAException, etc. This type is used to wrap whatever the framework exceptions thrown from the framework APIs and throw/re-throw when necessary. Since these components can be called in a hierarchical manner (DA calls Configuration, etc, ), I believe it would be easy to track from which component the exception is raised.

Well would this design make sense?

re: How to Design Exception Hierarchies

Roman Korchagin — Thu, 01 Feb 2007 00:32:17 GMT

Hi Krzysztof, grest post. We are an ISV and while we had no problems designing exceptions according to your guidelines, we are having a bit of a head scratch trying to document them in the public API. This is the question posted in my blog http://www.aspose.com/Community/blogs/aspose.words/archive/2007/01/27/66265.aspx. Thanks.

Exceptions thrown by Document constructors got better

Aspose.Words — Thu, 01 Feb 2007 01:30:18 GMT

According to many customers' requests we have improved design and documentation related to exceptions...

re: How to Design Exception Hierarchies

Alfred Myers — Thu, 01 Feb 2007 15:37:32 GMT

Thanuja,

You can track the component that raised the exception from the stack trace every Exception provides. Is there any other reason for creating your custom exceptions?

Hierarquia de exceções

How things (should) work — Thu, 01 Feb 2007 15:43:32 GMT

O Krzysztof Cwalina (pronuncia-se cristof sualina) escreveu um post interessante sobre o projeto e uso...

re: How to Design Exception Hierarchies

kcwalina — Sat, 03 Feb 2007 03:27:36 GMT

Thanuja, I would not catch and wrap unless you have a good reason for doing it. Being able to track which component raised an exception is not a good reason IMHO; you can get this information from the callstack. A good reason is if you want to abstract the internal implementation. More on this below.

Roman, documenting exceptions is hard. The reason is that it's actually not about just documenting exceptions, but more about being very explicit about the contract of the APIs. Specifying, describing, and keeping in compliance with contract requires deliberate design and takes time. But great reusable components must do it. The .NET framework does an ok job here and we are constantly thinking how to improve.

As to the specific questions, I would definitely document all exceptions you end up throwing from your component, even the ones thrown from the lower layers (e.g. the Framework).

But, I would be careful with letting implementation details leak through higher level abstractions. For example, you don't want to throw FileNotFoundException from database access APIs when the database is stored in a file. The fact that the data is stored in a file is an implementation detail that can change in the future. Same for things like configuration system APIs. The .NET config system is file based, but we don't (or at least I hope we don't) throw FileIO exceptions when the files get corrupted.

Now, when you catch and abstract (throw a different exception), you need to ensure that you leave the system in a known state such that client code can now handle your abstracted exception. Is no good to catch, wrap/abstract, and retrow a different exception that cannot be handled anyway because it would leave the internal implementation in an undefined state.

re: How to Design Exception Hierarchies

vijay — Thu, 07 Jun 2007 15:35:15 GMT

Hi Krzysztof, I am asking this question in a different context? how do you define hierarchies in business applicaitons? for e.g. if we have Customer related exceptions then should be have a base class like CustomerException and then let specific customer related exception inherit from this CustomerException like InvalidCustomerException? or there should be more generic BusinessException and for any conditions we throw this business exception. in consideration of Logging, I would like to have some specific business data to be logged. so considering this what are your suggestions for the hierarchy?

re: How to Design Exception Hierarchies

kcwalina — Mon, 11 Jun 2007 23:29:54 GMT

Vijay, I think same guidelines apply to bussiness applications: create a new exception if you can articulate reasons for the existance of the exception beyond just wanting to create a hierarchy.

re: How to Design Exception Hierarchies

Eran Nachum — Mon, 25 Jun 2007 18:38:49 GMT

Great post, very enjoyed reading it and got a nice prespective about all this issue.

I am inviting to take a look in my weblog at http://www.eranachum.com

re: How to Design Exception Hierarchies

Peter Pohmann — Wed, 15 Oct 2008 18:48:06 GMT

Hi Krzysztof,

I am currently designing the exception hierarchy for our new product. I started out with the difference between recoverable exceptions and non-recoverable exceptions and ended up at pretty much the same pattern as you did.

I would like to ask you about the SystemException class in the .NET framework. Is documented as "SystemException is thrown by the common language runtime when errors occur that are nonfatal and recoverable by user programs." Which would mean that it corresponds to what you are calling logical errors.

However, derived exceptions include ArrayTypeMismatchException, which is IMO a usage error and OutOfMemoryException, which is a system failure.

So I conclude that the documentation is not really helpful here and that SystemException is not a good base class for custom logical errors.

You said this implicitly already by advising to use Exception as the base class for such errors.

Do you agree?

Why catch(Exception)/empty catch is bad

CLR Team Blog — Fri, 20 Feb 2009 01:43:03 GMT

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

How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

Exceptions thrown by Document constructors got better

re: How to Design Exception Hierarchies

Hierarquia de exceções

re: How to Design Exception Hierarchies

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

re: How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

re: How to Design Exception Hierarchies

Why catch(Exception)/empty catch is bad