It seems like its not incredibly expensive as long as the stack isn't too deep but I've read conflicting reports. Just wondering if there is a definitive report out there that hasn't been rebutted.
+2
A:
I guess I'm in the camp that if performance of exceptions impacts your application then you're throwing WAY too many of them. Exceptions should be for exceptional conditions, not as routine error handling.
That said, my recollection of how exceptions are handled is essentially walking up the stack finding a catch statement that matches the type of the exception thrown. So performance will be impacted most by how deep you are from the catch and how many catch statements you have.
Colin Burnett
2009-05-21 03:01:25
@Colin while I agree with your statement, you're meandering off-topic and your tone is a little preachy.
Robert Paulson
2009-05-21 03:10:38
And then you have Java camp, where exceptions are encouraged.
Unknown
2009-05-21 03:20:56
If stating my opinion is "preaching", then so be it. My point still stands that if exceptions are impacting your performance then you need to throw fewer exceptions. It's not exactly what Chance's question is about but it most certainly is on topic. How am I supposed to know of Chance had considered my point already or not?
Colin Burnett
2009-05-21 03:23:17
Doesn't sound preachy to me. Actually sounds just like what Jon Skeet said, "If you ever get to the point where exceptions are significantly hurting your performance, you have problems in terms of your use of exceptions beyond just the performance."
RedFilter
2009-05-21 03:24:51
+8
A:
Jon Skeet wrote Exceptions and Performance in .NET in Jan 2006
Which was updated Exceptions and Performance Redux (thanks @Gulzar)
To which Rico Mariani chimed in The True Cost of .NET Exceptions -- Solution
Also reference: Krzysztof Cwalina - Design Guidelines Update: Exception Throwing
Robert Paulson
2009-05-21 03:03:31
+1
A:
Barebones exception objects in C# are fairly lightweight; it's usually the ability to encapsulate an InnerException that makes it heavy when the object tree becomes too deep.
As for a definitive, report, I'm not aware of any, although a cursory dotTrace profile (or any other profiler) for memory consumption and speed will be fairly easy to do.
Jon Limjap
2009-05-21 03:06:31
+2
A:
The performance hit with exceptions seems to be at the point of generating the exception object (albeit too small to cause any concerns 90% of the time). The recommendation therefore is to profile your code - if exceptions are causing a performance hit, you write a new high-perf method that does not use exceptions. (An example that comes to mind would be (TryParse introduced to overcome perf issues with Parse which uses exceptions)
THat said, exceptions in most cases do not cause significant performance hits in most situations - so the MS Design Guideline is to report failures by throwing exceptions
Gishu
2009-05-21 03:18:31
However, it *does* say exceptions should not normally be thrown: "Do not use exceptions for normal flow of control. Except for system failures, there should generally be a way to write code that avoids exceptions being thrown. For example, you can provide a way to check preconditions before calling a member to allow users to write code that does not throw exceptions."
Andrew Aylett
2010-02-02 11:40:43
@Andrew: Right. Maybe my response to another question will help clarify my stand http://stackoverflow.com/questions/859494/ . Throw exceptions only when the method is unable to carry out its reason for being.
Gishu
2010-02-02 12:28:21
@Gishu: Agreed :). I just wasn't sure that "report failures" was clear enough. I like those guidelines.
Andrew Aylett
2010-02-02 12:55:13