how does trycatch hurt the memory/CPU?

Question

so I am interested in the c# side of it - but I am tagging c++ as the concept exists there and I am not over the 'finally' keyword. So anyway - are there any benchmarks online about how try-catch would slow down or will use more memory than simple 'if-else' or other code?? For instance, now I am writing a code and using Streamwriter which shows 7 possible exceptions when you hold your mouse over it...so would anyone claim that it will be faster if i write something like:

//////////////
if(path is not too long)
{ if(file exists)
{ if(nothing else uses the file)
{ if(user is authorized)
}}}
////////////

You have 7 conditions and you can use instead just try-catch - not to mention that these conditions cannot be simplified to a single if statement.

10x!

Recommend closing as duplicate of: How expensive are exceptions in C#? Using Exceptions throwing in C#. Does it affect a performance? also information available at: http://msdn.microsoft.com/en-us/library/ms229009.aspx http://www.codeproject.com/KB/exception/ExceptionPerformance.aspx — holtavolt, Oct 08 '11 at 17:36
possible duplicate of [How expensive are exceptions in C#?](http://stackoverflow.com/questions/891217/how-expensive-are-exceptions-in-c) — John Saunders, Oct 08 '11 at 17:38

score 7 · Answer 1 · edited May 23 '17 at 11:55

try/catch has a slight performance cost if the exception occurs, but compared to file access the cost is not worth worrying about.

More important is that try/catch is correct, the nested ifs are not, because the filesystem is a shared resource that can be modified asynchronously. Handling the error or exception result of actually opening the file is the only way to avoid a race condition.

See

These examples all use files, but there's a general principle here for shared resources.

score 1 · Answer 2 · answered Oct 08 '11 at 17:38

Any performance differences are not really the point.

Testing that a file exists at some point before opening it does not guarantee that another thread or process has not deleted or locked the file; you only know at the point of attempting to open it whether or not you have succeeded. Hence OS calls often return success or failure codes, or return a known value to indicate an invalid file handle.

In an object oriented environment, it's cleaner to use the idiom that creating the object acquires the resource (RAII) then you have to throw an exception rather than allow an invalid object to be created. Alternatively, you could have an object-oriented OS interface which returned a reference to a known bad object ( e.g. null ), but then you're delaying the exception to a later point in the program, so may not know what file failed to open.

The other advantage is that it allows the library providing the object to decide what the conditions for its validity are - if the file were actually a link to a WebDav server say, then other conditions such as presence of a valid network interface would be required. By having the library take care of the conditions, the implementation details are hidden from the client code (this applies to library APIs as to try/catch)

Oftentimes, the best idiom is the tryIt/doIt pattern, where many methods exist in both "tryDoSomething" and "DoSomething" forms. For example, a method "OpenWuzzleFile" would throw an exception if it can't open the file as expected, while a "TryOpenWuzzleFile" method would, for many types of errors, return with an error code instead of throwing an exception. If it's expected that users of a method "DoSomething" will likely put a DoSomething call by itself in a try/catch block, that's a good sign that the method should support a "TryDoSomething" variant. — supercat, Oct 08 '11 at 23:52

score 0 · Answer 3 · answered Oct 08 '11 at 17:52

For a truly brilliant discourse on Exceptions handling and its ramifications (be it cost, system stability, etc..) I recommend reading Chapter 20 of the great work "CLR via C#" by Jeffrey Richter. It will definitely answer most of your questions and help understand how .NET framework handles exceptions under the hood, and how use Performance Counter as a mean to assess the impact of the exceptions your code throws.

Using Guard Clauses (as you mention in your question) is not an alternative to exception handling, they are two complimentary concepts. A guard condition such as if(file exists) might short circuit the rest of the conditions and yield better performance since your code may not need to test the following conditions i.e. if(user is authorized) might be resource intensive or time consuming.

how does trycatch hurt the memory/CPU?

3 Answers3