Custom Exceptions Cost

Question

I read that throwing exceptions is an expensive operation. However, without creating your own exceptions, is your code more expressive and readable?

Some of my employees suggest you simply use System.Exception and insert your text in the message instead of creating a new custom exception.

I am interested in other opinions. Appreciate any suggestions.

Answer 1

Do not throw a System.Exception . Someday.

The problem with this is the call code. Bad practice is to catch a common Exception object for many reasons. If you throw an instance of the base class Exception , then calling the code has no choice but to catch Exception if it wants to handle it. This forces the calling code to use bad practice.

In addition, the calling code does not have reliable means to highlight what an exception is if all it receives is an Exception .

It is usually best to use one of the predefined exceptions if applicable ( ArgumentException , InvalidOperationException , etc.). If they do not correctly describe the situation, then a special class of exceptions is a great way.

Answer 2

This is the overhead of throwing the exception itself (creating an object, walking on a stack, etc.), which is expensive. Creating your own exception class adds almost no overhead, so if you are going to throw an exception, do not throw it new Exception("message") !

Answer 3

Exceptions are not intended to be read by people (although their messages and stack traces are read by people), they are intended to be read by code. If there is anything your code can do in response to a custom exception, by all means. But the exception is just for registration, it makes no sense to create a custom one.

The overhead of custom exceptions is that they are another thing to maintain and test. If an existing exception is appropriate, use this instead. (For example, ArgumentNullException instead of ZipCodeNullException .)

Answer 4

• If there is a reason your exception will be caught and handled differently than standard exceptions, then you should create your own class.
• If there is any reason why your exception accepts different arguments (for example, to create a specially formatted message based on a set of arguments that usually occur frequently), you should create your own class.

In any other case, you can just use Exception . Generally speaking, it’s actually not worth creating an instance or throwing a custom exception any more than a standard exception, at least not comparing it with the costs of throwing an exception in the first place. Exceptions, by definition, should be exceptional, and therefore performance during the throwing of an exception is not a problem. The point is to have all the necessary information when the time comes to see why this exception was thrown.

Answer 5

Your colleague says nonsense. Throwing an exception is the same cost, regardless of class.

And frankly, all this talk about “expensive” exceptions is yes, they are more expensive than zero checking or some of them, so never use them as a substitute for any sanity check, but they should be encouraged where they make sense (for example, an IOException exception, which is an excellent precedent for them - I / O problems are an exceptional case, and they usually need to be handled outside the normal program flow).

Answer 6

You should never throw a System.Exception , because then the only way to catch is catch(System.Exception) . It is very bad practice to catch such an exception. You must catch certain exceptions that give you the ability to handle it correctly without software crashes. By creating custom exceptions, you are giving yourself the opportunity to potentially recognize and recover them.

For example, if your code means opening a file and you get an unknown exception, how did you recover from it? However, if you catch a specific File Not Found exception that is much easier to recover from. You can permanently tell the user that the file does not exist.

I see no reason to believe that custom exceptions are more expensive than built-in ones.

Answer 7

“Darling” is a relative term, and as already mentioned, an exception should be an exception, so it probably won't affect the performance of your code. The cost of throwing an exception is, to my knowledge, regardless of the type of exception, so you should not limit yourself to a System.Exception exception.

But most importantly: http://c2.com/cgi/wiki?PrematureOptimization

Answer 8

I prefer to use the most appropriate built-in exception, and if that doesn't already exist, throw my own out of System.ApplicationException.

I would not recommend throwing a System.Exception with a special message.