Comment Feed for Exceptions (Posts on Channel 8)

Re: Re: Re: Re: Re: Exceptions

gogole — Wed, 28 May 2008 22:15:48 GMT

Thanks diegum. :)

Re: Re: Re: Re: Exceptions

diegum — Thu, 22 May 2008 22:18:23 GMT

I believe my folks answered your questions on Exceptions, Donald. I've just got some few more guidance on that coming directly from MS architects related with .NET framework evolution

The 1st one is and old book on performance and scalability (although it's on .NET 1.1, the statements on Exception Management yet apply to the current versions of that managed environment). Worth reading: http://msdn.microsoft.com/en-us/library/ms998547.aspx#scalenetchapt05_topic24

The other useful reference is a session delivered by Krzysztof Cwalina (father of the .NET Base Class Library). While the session is about more than three hours on framework development guidance (worth saving the time to watch it all), the particular part for Exception Management comes at 2:23:11 (two hours, twenty three minutes, eleven seconds :-)
http://www.researchchannel.org/prog/displayevent.aspx?rID=11087&fID=2740

Krzysztof summarized all his thought on exception handling on chapter 7 of his best-seller "Framework Design Guidelines", whose second edition is coming next year

Re: Re: Re: Exceptions

chakkaradeep — Fri, 16 May 2008 07:08:27 GMT

I have blogged on it :) (the posts have external links too associated with it)

Re: Re: Exceptions

gogole — Fri, 16 May 2008 02:34:04 GMT

A link to TDD and Agile dev introduction would be helpful ;)

Re: Exceptions

chakkaradeep — Fri, 16 May 2008 01:25:11 GMT

Actually, If you start using Agile methodologies and Test Driven Development, You eliminate all those NullReferenceExceptions, ArgumentExceptions etc. ;)

Re: Re: Re: Exceptions

gogole — Thu, 15 May 2008 13:21:20 GMT

Great feedback from you guys. I'll keep your info in mind and i sheepishly accept my testing blunder , i should have run more tests.
Since exceptions should be as specific as possible , when catching them it is a good idea to make use of the exception instance like : catch (NullReferenceException ex){}. With this you'd have access to properties like the exception's stacktrace ,generated message ,source etc which would help in handling the exception.

Re: Re: Re: Exceptions

littleguru — Thu, 15 May 2008 13:11:47 GMT

Interesting that you mention the error code vs exception discussion. I'm really much on the exception side there. Because my idea is to throw an exception only if you are already doomed. In that case the few ms that you loose don't count... I, also don't like error codes because you can simply ignore them. That's what often happens in older applications and then results in weird crashes that nobody understands anymore...

Re: Re: Exceptions

gbarnett — Thu, 15 May 2008 09:10:55 GMT

Christian mentioned the most important point - only catch what you can handle. All too often I see people catching Exception which is just very , very bad.

I would run something to gather a nice variation of data a few hundred times and perform other forms of statistical analysis on that data to see a true representation of the values collected (e.g. variance, std dev).

The reason I tend to run things so many times, is because of the scheduler - as the system can be allowing other higher priority processes to utilize the CPU of which their is a varying number at any time.

I think what has been touched on is actually pretty interesting as it brings up the whole Exceptions vs Error code argument, the latter of which tends to be preferred in systems code for the reason Christian mentioned - throwing exceptions IS expensive.

Another one to watch out for is not not rethrow an exception by saying something like throw ex; rather just put a straigth throw; to preserve the call stack.

In general I think Christian mentioend the things I would of but I've thrown in a few others as its a pretty interesting area in terms of API design.

Re: Exceptions

littleguru — Thu, 15 May 2008 07:44:40 GMT

Btw., Donald, if you test something like this you need to run it more often... if you run such tests only 3 times there could be a lot of things that influence your testing; like another app could run at higher priority and steal CPU time etc. Also you should always specify on what system you tested; otherwise people don't know how how to put the numbers in relation.

Re: Re: Exceptions

littleguru — Thu, 15 May 2008 07:42:09 GMT

The deal is the following: only putting a try-catch(-finally) into your code doesn't make your application slower; and that's good! If you throw an exception that takes some time because the stack needs to be walked etc.

Therefore exceptions shouldn't be used for program flow; that means that you don't use exceptions to exit a method or branch or similar... there are other constructs like return, if etc for that. Never use exceptions for that.

If you follow these guidelines you only throw exceptions if you reach a state (in your app) that's not valid. Like you tried to access something that's null or you open a file that's not existent etc. In other words: when you throw an exception something got terribly wrong and you can't do much about it. In that case it isn't important if your exceptions take like a few milliseconds more because they happen very rare and therefore don't influence your performance much.

If you take for example the exception that's thrown when you open a file that doesn't exist. You can always avoid that by checking if the file exists in the first place. There are methods to do that. The same applies to null reference exceptions. You can always check if the array (to take Donald's example) has been initialized. If it hasn't perhaps you can only return from the method with a false or something similar...

Exception might include user input to fix the problem or the application might completely crash; but that's fine!

There's also another point with exceptions: people think they are evil and that they need to catch all of them. Never do that. Always only catch what you can handle. All the other stuff don't catch; even if your application crashes. Try to understand what crashed the application and see then if you could handle the crash somehow; if you can't don't do anything.

Re: Exceptions

Trix — Thu, 15 May 2008 04:58:18 GMT

I wonder how many people actually think of things like this...I'm glad someone does though ;)