Design Guidelines Update: Exception Throwing

How to get .NET Framework Design Guidelines Updates [Krzysztof Cwalina]

BCLTeam's WebLog — Wed, 16 Mar 2005 17:51:00 GMT

re: Design Guidelines Update: Exception Throwing

Rolando — Wed, 16 Mar 2005 19:00:00 GMT

"Do not create and throw new exceptions just to have ‘your team's’ exception." I was planning to do exactly that so we can identify exceptions thrown by our own code. Could you explain why this is a bad idea ? thanks.

re: Design Guidelines Update: Exception Throwing

damien morton — Wed, 16 Mar 2005 19:48:00 GMT

Python uses what is called the "samurai principle" for determining when to throw exceptions:

Return a meaningfull and useable result or else throw an exception.

I find that the standard prescription "exceptions are for exceptional circumstances" doesnt give much guidance, and welcome these new guidelines.

Design Guidelines Update: Exception Throwing

Richard Murillo's Blog — Wed, 16 Mar 2005 19:56:00 GMT

Guidelines para o uso de excep

LA.Net — Wed, 16 Mar 2005 20:26:00 GMT

re: Design Guidelines Update: Exception Throwing

Jacques Troux — Thu, 17 Mar 2005 01:54:00 GMT

"Do not return error codes. Exceptions are the primary means of reporting errors in frameworks."

Blech. One more reason for me to stay away from .net.

re: Design Guidelines Update: Exception Throwing

Jeroen Frijters — Thu, 17 Mar 2005 13:22:00 GMT

So what do you make of Thread.Abort() that (on Whidbey, if the thread is suspended) throws an exception *and* schedules an abort?

re: Design Guidelines Update: Exception Throwing

mihailik — Thu, 17 Mar 2005 16:25:00 GMT

Question on AgumentNullException. What exception to throw if my method does not allow "" (empty string) and such argument was passed in? In some place of CLR I have seen ArgumentNullException, but String.Empty is definitely not null. What is the guideline here? Please claim this option to official document, that all developers have to deal same way.

re: Design Guidelines Update: Exception Throwing

Rolando — Thu, 17 Mar 2005 16:25:00 GMT

"Do not create and throw new exceptions just to have ‘your team's’ exception." Could you explain why ? We were planning to do this so we can identify the exceptions thrown by our code.

re: Design Guidelines Update: Exception Throwing

mihailik — Thu, 17 Mar 2005 16:31:00 GMT

Jacques Troux: it is phylosophical discussion. Miguel de Icaza — leader of Mono, a.k.a. .NET for Linux — Miguel votes for error codes in some of his old messages. And you can find the interview with Anders Heilsberg — author of C# — that expressively votes for exceptions. All .NET ideology built with exceptions, and it is extrmely important for security and stability.

re: Design Guidelines Update: Exception Throwing

Joe Duffy — Thu, 17 Mar 2005 23:13:00 GMT

Jeroen, you're correct about the behavior. I wouldn't recommend following the pattern that Thread.Abort() uses. (Note: I wouldn't recommend suspending and asynchronously aborting threads either, but that's a wildly separate topic. :)) The behavior is strange. It succeeds at provoking an abort, but does throw an exception. I wish we could change it, but it's been that way since 1.0.

re: Design Guidelines Update: Exception Throwing

David M. Kean — Fri, 18 Mar 2005 08:04:00 GMT

What does FailFast do? I can't find any documentation on it.

re: Design Guidelines Update: Exception Throwing

Jeffrey Sax — Fri, 18 Mar 2005 20:12:00 GMT

This guideline is mostly excellent, but confusing in one respect.

This performance rule:

"Do not use error codes because of concerns that exceptions might affect performance negatively."

is violated by the TryParse pattern. The TryParse pattern is worded nicely, but still clearly uses an error code to indicate success or failure.

This contradiction, and the confusion that comes with it, disappear if you qualify the first rule with "except in extremely performance demanding APIs," and then suggest to "Do use" the TryParse pattern for these situations.

re: Design Guidelines Update: Exception Throwing

Jonathan Keljo [MS] — Fri, 18 Mar 2005 20:41:00 GMT

System.Environment.FailFast offers the user a chance to send an error report, then terminates the process. (It's the nicer managed equivalent to calling ExitProcess when you decide you really can't go on.) If you're writing a class library you probably don't want to use FailFast--at least not if you like having customers :-D. If you're writing an application, though, it often makes sense if you really want the process to die. Exceptions can be caught; FailFast just kills the process right away.

re: Design Guidelines Update: Exception Throwing

Jonathan Keljo [MS] — Fri, 18 Mar 2005 22:26:00 GMT

Here's how I think about the performance rule and Parse vs. TryParse: Parse says it’s going to parse something. “Failure” means it couldn’t parse it. So exceptions from Parse could include exceptions because what you passed to it wasn’t parseable. The return value is the result of the operation—the parsed value. TryParse says it’s going to try to parse something. “Failure” means that it wasn’t even able to _try_ to parse the thing. Thus the only kinds of exceptions you’re going to get out of TryParse are things like OutOfMemory from JITting or allocating buffers before it even gets a chance to look at the string to be parsed. (You wouldn’t expect to get an exception because the value wasn’t parseable…the point is the method said it was going to try, and it did try. It did what it said it would, so no exception needed.) TryParse really has two results—was the thing parseable, and if so the parsed value.

re: Design Guidelines Update: Exception Throwing

Vincent — Sun, 20 Mar 2005 19:37:00 GMT

Hello,

FYI: your blog renders completely wrong in Firefox.

re: Common Exception Types

Brad Abrams — Tue, 29 Mar 2005 03:05:00 GMT

Hey, what's with the display?

Goran Pušić — Wed, 30 Mar 2005 10:38:00 GMT

"FYI: your blog renders completely wrong in Firefox."

Um... In IE, too!?!? (IE6 on Wn2003)

OTOH, like the contents and the reasoning.

re: Design Guidelines Update: Exception Throwing

dan — Thu, 31 Mar 2005 05:14:00 GMT

It isn't clear whether you prohibit exceptions from /containing/ error codes (as a property). This ought to be allowed, because in some circumstances your only other options are (a) having a huge set of different exception types or (b) parsing the exception message to figure out what exactly happened. An example of this problem is XmlException, which can be thrown for 1000 different reasons and needs an error code property to distinguish it.

Exception Throwing Design Guidelines : Creating our own team exception

Rolando Ramirez's WebLog — Tue, 05 Apr 2005 18:31:19 GMT

Exception Throwing Design Guidelines : Performance (another religious war?)

Rolando Ramirez's WebLog — Tue, 05 Apr 2005 18:45:17 GMT

Exception Throwing Design Guidelines : Performance (another religious war?)

Rolando Ramirez's WebLog — Tue, 05 Apr 2005 19:25:54 GMT

Exception Throwing Design Guidelines : Creating our own team exception

Rolando Ramirez's WebLog — Tue, 05 Apr 2005 22:41:01 GMT

Design Guidelines Update: Exception Throwing

Richard Murillo's Blog — Fri, 22 Apr 2005 11:17:00 GMT

Should Exceptions Carry Error Code Information

Krzysztof Cwalina — Fri, 27 May 2005 22:12:57 GMT

Recently somebody asked me to clarify one of the exception guidelines. They were asking whether it's...

Guide on exceptions

Wouter van Vugt — Wed, 10 Aug 2005 09:15:53 GMT

Design guidelines for exception throwing

Jeff Stong — Tue, 06 Jun 2006 21:21:28 GMT

In a recent post I mentioned the .NET framework design guidelines and that reminded me of a post by Krzyztof...

Choosing the Right Type of Exception to Throw

Krzysztof Cwalina — Thu, 06 Jul 2006 01:17:19 GMT

My last post about the ApplicationException resulted in some questions along the lines of “so, if not...

re: Design Guidelines Update: Exception Throwing

JP — Sat, 29 Jul 2006 17:49:04 GMT

The use of the word Throw has mulitple meanings in .net. As a result the article is somewhat ambiguous. In object oriented design, the standard of an object is that it is responsible for it's own function. Therefore, it is my understanding that objects and or methods within, should not Throw anything. Instead they should handle the exception and move on. Does your term throw mean "Handle the exception and inform the user?"

re: Design Guidelines Update: Exception Throwing

kcwalina — Sat, 29 Jul 2006 18:40:57 GMT

I agree that the term “throwing” is a bit ambiguous. It means either executing the throw statement or allowing an exception propagate out of a publicly callable API.

I am not sure why you interpret throwing as handling exceptions and showing them to users. Could you point me to any particular statements that might imply so?

As to objects handling exceptions and moving on, I think it’s only true for some kinds of exceptions. There are others that simply cannot be handled because the object does not have enough context to know how to fix the state of the system in the exception handler so it could continue safely. Those can sometimes be handled higher up on the stack, but in some cases they cannot be handled at all, and the best approach is to record as much information as possible and shut down the process/app domain.

JP, please feel free to email me directly (kcwalina_at_microsoft.dot_com) if you'd like to talk about this more.

re: Design Guidelines Update: Exception Throwing

AlSki — Mon, 11 Sep 2006 23:58:10 GMT

I came across this article on Exception Throwing by Krysztof Cwalina, and I didn't think its all very good advice... (See http://www.alski.net/software/Throwing+Exceptions.aspx)

re: Design Guidelines Update: Exception Throwing

kcwalina — Fri, 15 Sep 2006 02:36:03 GMT

AlSki, I posted a reply comment on your blog. I hope it clarifies some things. Please don't hesitate to email me at kcwalina_at_microsoft.com. I would be happy to discuss more detail.

re: Design Guidelines Update: Exception Throwing

Chris — Tue, 30 Jan 2007 17:39:08 GMT

Can you provide some guidance for how to structure a hierarchy of exception classes? I cannot find any information addressing this design issue. Should exceptions be grouped by the type of data that the error is associated with, or by the type of error. I think they should be organized by the type of error, but it is very difficult to group errors this way. Thank you for any input you may have.

re: Design Guidelines Update: Exception Throwing

NigelAston — Thu, 22 Feb 2007 10:38:08 GMT

How would you recommend handling multiple 'error' types that are passed back from hardware devices? For example we are a driving a motor to cause movement, and the command 'move()' can fail for many reasons such as 'HitEndStop', "Stall", "PowerLoss". Currently we would do something like:

CError MoveTheDevice()

{

CError error = Move();

if (error.IsOk)

{

//... continue processing

}

return error; // to pass status higher up

}

Should we create lots of exception types and map the device errors to exception types?

should we throw an exception, having recorded the 'error' code somewhere - maybe as a 'parameter' within the exception.

re: Design Guidelines Update: Exception Throwing

Sloan — Thu, 26 Apr 2007 04:14:06 GMT

Krzysztof ,

Thank you for the great article. Your ideas are clear and well laid out, and have helped tremendously.

NigelAston,

One way I deal with this scenario is using a "base" exception.

public abstract class HardwareFailureException : System.ApplicationException

public class HitEndStopException : HardwareFileException

public class PowerLossException : HardwareFileException

Then I believe you can just catch the HardwareFileException exception in your code.

Give it a try!

re: Design Guidelines Update: Exception Throwing

CVC — Thu, 19 Jul 2007 19:01:14 GMT

Performance is a criteria to take into consideration, but one criteria that is not included in this article is code flow, throwing exceptions sometimes makes you code flow nicer than trying to exit your method earlier and trying to clean up, when you finally statement could handle that, returning error codes from your method when it happens, etc.... I assume that this guidelines apply to exceptions that could occur in .net system classes, but what about classes that I create? If have not seen any issues with performance in throwing exceptions in my production application...It has made the flow of my program much cleaner and easier to understand.

Tratando con excepciones

Pensando en asíncrono — Sun, 09 Dec 2007 22:24:01 GMT

Buff... cuanto tiempo desde mi último post, entre estudiar y la medio-gripe que arrastro desde hace unas

Tratando con excepciones

vtortola — Sun, 09 Dec 2007 22:25:46 GMT

Buff... cuanto tiempo desde mi último post, entre estudiar y la medio-gripe que arrastro desde hace unas

Still Learning » Blog Archive » Exception vs. Error Codes in C++

Still Learning » Blog Archive » Exception vs. Error Codes in C++ — Wed, 02 Jan 2008 05:26:21 GMT

PingBack from http://imehta.com/blog-ketan/?p=15

Izņēmuma situāciju lietošana

Ivara blogs — Thu, 10 Jan 2008 03:20:08 GMT

Šodien   Vakar Andrejs jau aizskāra tēmu, par kuru es jau pasen gribu uzrakstīt, bet kaut kā

re: Design Guidelines Update: Exception Throwing

rakhs — Thu, 10 Jan 2008 11:33:43 GMT

Gud one.

how we can throw exceptions from Appdomain "A" to appDomain "B".

Scenario:

In AppDomain "B" create a thread and from worker thread call a method in AppDomain "A" , which throws an exception. How we can catch this exception in AppDomain "B"

Dum spiro, spero » Blog Archive » .NET Exceptions, Performance and Guidelines

Dum spiro, spero » Blog Archive » .NET Exceptions, Performance and Guidelines — Fri, 07 Mar 2008 12:52:32 GMT

PingBack from http://blog.sanny.maniacs.nu/2008/03/07/net-exceptions-performance-and-guidelines/

ASP.NET Exception Handling Best Practices

Janko's Blog — Sat, 08 Mar 2008 15:22:33 GMT

Exception handling plays an important part of application management and user experience. If implemented

re: Design Guidelines Update: Exception Throwing

Licantrop0 — Mon, 10 Mar 2008 14:28:13 GMT

Hi Krzysztof, Iv'e bought your book and is one of my favourites.

I wanna ask if you can spend some word about the bad design to rise normal events (named "whateverError" or "whateverException") instead of throwing exceptions.

thanks.

re: Design Guidelines Update: Exception Throwing

kcwalina — Tue, 11 Mar 2008 21:23:41 GMT

In rare cases it's better to communicate errors through events. This is true mainly for asynchronous APIs where the original caller thread is long doing some other things and we can not throw to that thread anymore.

re: Design Guidelines Update: Exception Throwing

Licantrop0 — Wed, 12 Mar 2008 11:33:45 GMT

Thanks for your reply.

So except for multithreading environment, throwing exception is always the best way. I have many colleagues that sadly mix up event and exception so "you can manage what you prefer!" ... :|

Could you please write a little explanation about this in your new book?, so if "the .net guidelines bible said so", they can't complain... :)

regards!

re: Design Guidelines Update: Exception Throwing

kcwalina — Mon, 17 Mar 2008 19:52:05 GMT

I will try to clarify that in the book (2nd edition), but it already says that exceptions should be the default and other means of communicating errors should be very rare.

Liste over exceptions i .NET

Liste over exceptions i .NET — Wed, 26 Mar 2008 13:11:10 GMT

PingBack from http://blog.todobom.dk/post/Liste-over-exceptions-i-NET.aspx

Parsing strings with the TryParse method

Fri, 28 Mar 2008 02:03:59 GMT

This post was originally published here . I recently posted on the out and ref keywords in C#, and mentioned

re: Design Guidelines Update: Exception Throwing

Andrei Rinea — Sun, 25 May 2008 17:16:42 GMT

A person asked above what should do in case the method called gets an empty string (String.Empty) and such a value is not acceptable?

Throwing an ArgumentNullException is not the best idea and ArgumentException might be a little too ambigous.

I always thought of ArgumentEmptyException as an exception class derived from ArgumentException.

What can you tell us about this issue?

An example of the interplay between language features and library design, part one | abortive

Fri, 11 Jul 2008 14:22:23 GMT

PingBack from http://www.abortive.com.cn/?p=31

Luke Smith » Blog Archive » Sometimes you have to catch an exception

Thu, 31 Jul 2008 23:43:29 GMT

PingBack from http://blog.lukesmith.net/index.php/2008/07/31/sometimes-you-have-to-catch-an-exception/

异常的性能及抛出(Exception Throwing)

译时代 — Fri, 10 Oct 2008 20:14:17 GMT

1.抛出异常（ExceptionThrowing）

抛出异常在这篇文章里被定义为是对执行失败时给出的定义。执行失败在任何时候都引出了一个被设计好的程序不去做它应该做的事情。例如，如果打开一个文...

Favor structured exception handling | Anders Lybeckers Weblog!

Favor structured exception handling | Anders Lybeckers Weblog! — Fri, 17 Oct 2008 21:55:41 GMT

PingBack from http://www.lybecker.com/blog/2007/02/21/favor-structured-exception-handling/

Best practice error handling? | keyongtech

Best practice error handling? | keyongtech — Sun, 18 Jan 2009 20:35:43 GMT

PingBack from http://www.keyongtech.com/551906-best-practice-error-handling

re: Design Guidelines Update: Exception Throwing

VS — Mon, 19 Jan 2009 08:47:02 GMT

mihailik:

AFAIK, there is no built in Exception class to check for empty arguments. What I can suggest is this:

In your method, do this:

if String.IsNullOrEmpty(param)

{

throw new ArgumentException("The param cannot be null or an empty string.");

}

Can somebody comment?

Exception Handling | keyongtech

Exception Handling | keyongtech — Thu, 22 Jan 2009 09:45:45 GMT

PingBack from http://www.keyongtech.com/433205-exception-handling

Krzysztof Cwalina Design Guidelines Update Exception Throwing | fix my credit

Krzysztof Cwalina Design Guidelines Update Exception Throwing | fix my credit — Wed, 17 Jun 2009 04:35:58 GMT

PingBack from http://fixmycrediteasily.info/story.php?id=10173

Krzysztof Cwalina Design Guidelines Update Exception Throwing | Outdoor Decor

Krzysztof Cwalina Design Guidelines Update Exception Throwing | Outdoor Decor — Fri, 19 Jun 2009 07:17:13 GMT

PingBack from http://outdoordecoration.info/story.php?id=1835