Develop Reference

Which is the best practice to use try - catch blocks with foreach loop? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
what is the best practice to use try{} catch{} blocks regarding performance ?
foreach (var one in all)
{
try
{
//do something
}
catch { }
}
Or
try
{
foreach (var one in all)
{
// do something
}
}
catch { }

No hard and fast rule to be fair, it's situational.
It depends on whether you want to stop the whole loop if one of the items causes an issue, or just catch that single issue and continue.
In example, if you are sending email's to people, you wouldn't want to stop processing if an exception occurs sending one of them, but if you are managing a set of database transactions and need to rollback if any of them fail, maybe it is more desirable to stop processing at that point on exception/issue?

As per request, here is my cool answer. Fun part will be at end, so if you already know what try-catch is, feel free to scroll. (Sorry for partial off-topic)
Lets start by answering concept of try-catch in general.
Why? Because this question suggest lack of full knowledge how, and when, to use this feature.
What is try-catch? Or rather, what is try-catch-finally.
(This chapter is also known as: Why the hell have you not used Google to learn about it yet?)
Try - potentially unstable code, which means you should move all
stable parts out of it. It is executed always, but without guaranty
of completion.
Catch - here you place code designed to correct failure which
occurred in Try part. It is executed only when exception occurred in
Try block.
Finally - its third and last part, which in some languages may not
exists. It is always executed. Typically it is used to release
memory and close I/O streams.
In general, try catch is a way to separate potentially unstable code from rest of program.
In terms of machine language it can be shortened to placing values of all processor registers on stack to save them from corruption and then informing environment to ignore execution errors as they will be manually handled by code.
Whats the best practice of using try-catch blocks?
Not using them at all. Covering code with try-catch means that you are expecting it to fail. Why code fails? Because its badly written.
It is much better, both for performance and quality, to write code that need no try-catch to work safely.
Sometimes, especially when using third-party code, try-catch is easiest and most dependable option, but most of the time using try-catch on your own code indicates design issues.
Examples:
Data parsing - Using try-catch in data parsing is very, very bad. There are tons of ways to safely parse even weirdest data. One of ugliest of them is Regular Expression approach (got problem? Use regexp, problems love to be plural). String to Int conversion failed? Check your data first, .NET even provides methods like TryParse.
Division by zero, precision problems, numerical overflow - do not
cover it with try-catch, instead upgrade your code. Arithmetic code
should start as good math equation. Of course you can heavily modify
mathematical equations to run a lot faster (for example by
0x5f375a86), but you still need good math to begin with.
List index out of bounds, stack overflow, segmentation fault,
Heartbleed - Here you have even bigger fault in code design. Those
errors should simply not happen in properly written code running in
healthy environment. All of them come to one simple error, code have
made sure that index (memory address) is in expected boundaries.
I/O errors - Before attempting to use stream (memory, file,
network), first step is to check if stream exists (not null, file
exists, connection open). Then you check if stream is correct - is
your index in its size? Is stream ready to use? Is its queue/buffer
capacity big enough for your data? All this can be done without
single try catch. Especially when you work under framework (.NET,
Java, etc).
Of course there is still problem of unexpected access issues - rat
munched your network cable, hard disk drive melted. Here usage of
try-catch can not only be forgiven but should occur. Still, it needs
to be done in proper manner, such as this example for files.
You should not place whole stream manipulating code in try-catch,
instead use built in methods to check its state.
Bad external code - When you get to work with horrible code library,
without any means of correcting it (welcome to corporate world),
try-catch is often only way to protect rest of your code. But yet
again, only code that is directly dangerous (call to horrible
function in badly written library) should be placed in try-catch.
So when should you use try-catch and when you shouldn't?
It can be answered with very simple question.
Can I correct code to not need try-catch?
Yes? Then drop that try-catch and fix your code.
No? Then pack unstable part in try-catch and provide good error handling.
How to handle exceptions in Catch?
First step is to know what type of exception can occur. Modern environments provide easy way to segregate exceptions in classe. Catch most specific exception as you can. Doing I/O? Catch I/O. Doing math? Catch Arithmetic ones.
What user should know?
Only what user can control:
Network error - check your cables.
File I/O error - format c:.
Out of memory - upgrade.
Other exceptions will just inform user on how badly your code is written, so stick to mysterious Internal Error.
Try-catch in loop or outside of it?
As plenty of people said, there is no definitive answer to this question. It all depends on what code you committed.
General rule could be:
Atomic tasks, each iteration is independent - try-catch inside of loop.
Chain-computation, each iteration depends on previous ones - try-catch around the loop.
How different for and foreach are?
Foreach loop does not guarantee in-order execution. Sounds weird, almost never occur, but is still possible. If you use foreach for tasks it was created (dataset manipulation), then you might want to place try-catch around it. But as explained, you should try to not catch yourself using try-catch too often.
Fun part!
The real reason for this post is just few lines from you, dear readers!
As per Francine DeGrood Taylor request I will write a bit more on fun part.
Have in mind that, as Joachim Isaksson noticed, its is very odd at first sight.
Although this part will focus on .NET, it can apply to other JIT compilers and even partially to assembly.
So.. how it is possible that try-catch around loop is able to speed it up?
It just does not make any sense! Error handling means additional computation!
Check this Stackoverflow question about it: Try-catch speeding up my code?
You can read .NET specific stuff there, here I will try to focus on how to abuse it.
Have in mind that this question is from 2012 so it can as well be "corrected" (it is not a bug, its a feature!) in current .NET releases.
As explained above, try-catch is separating piece of code from rest of it.
Process of separation works in similar manner to methods, so instead of try-catch, you could also place loop with heavy computations in separate method.
How separating code can speed it up? Registers. Network is slower than HDD, HDD than RAM, RAM is a slowpoke when compared to ultrafast CPU Cache. And there are also CPU Registers, which laugh at how slow Cache is.
Separating code usually means freeing up all general purpose registers - and that's exactly what try-catch is doing. Or rather, what JIT is doing due to try-catch.
Most prominent flaw of JIT is lack of precognition. It sees loop, it compiles loop. And when it finally notices that loop will execute several thousands times and boast calculations which make CPU squeak it is too late to free registers up. So code in loop must be compiled to use whats left of registers.
Even one additional register can produce enormous boost in performance. Every memory access is horribly long, which means that CPU can be unused for noticeable amount of time. Although nowdays we got Out-of-Order execution, cute pipelines and prefetching, there are still blocking operations which force code to halt.
And now lets talk why x86 sucks and is trash when compared to x64. The try-catch speed gain in linked SE question did not occur when compiled for x64, why?
Because there was no speed-gain to begin with. All that existed was speed-loss caused by crappy JIT output (classic compilers do not have this issue).
Try-catch corrected JIT behavior mostly by accident.
x86 registers were created for certain tasks. x64 architecture doubled their size, but it still can't change the fact that when doing loop you must sacrifice CX, and similar goes for other registers (except poor orphan BX).
So why x64 is so awesome? It boasts 8 additional 64bit wide registers without any specific purpose. You can use them for anything. Not just theoretically like with x88 registers, but really for anything. Eight 64 bit registers means eight 64bit variables stored directly in CPU registers instead of RAM without any problem for doing math (which requires AX and DX for results quite often). What also 64bit means? x86 can fit Int into register, x64 can fit Long. If math block will have empty registers to work at, it can do most of work without touching memory. And that's the real speed boost.
But it is not the end! You can also abuse Cache.
The closer Cache gets to CPU, the faster it becomes, but it also will be smaller (cost and physical size are limits). If you will optimize your dataset to fill in Cache at once, eg. date chunks in size of half of L1, leave other half for code and whatever CPU finds necessary in cache (you can not really optimize it unless you use assembly, in high level languages you have to "guestimate"). Usually each (physical) core have its own L1 memory, which means you can process several cached chunks at once (but it won't be always worthy overhead from creating threads).
Worthy of mentioning is that old Pascal/Delphi used "16 bit dinosaurs" in age of 32bit processors in several vital functions (which made them two times slower than 32bit ones from C/C++). So love your CPU Registers, even poor old BX. They are very grateful.
To add a bit more, as this became rather insane post already, why C#/Java can be at same time slower and faster than native code? JIT is the answer, framework code (IL) is translated to machine language, which means that long calculation blocks will execute just as native code of C/C++. However remember that you can easily use native components in .NET (in Java you can get crazy by attempting it). For computation complex enough you can cover overhead from switching managed-native modes with speed-gain of native code (and native code can be boosted by asm injects).

Performance is probably the same in either case (but run some tests if you want to be sure). The exception checks are still happening each time through the loop, just jumping somewhere else when caught.
The behavior is different, though.
In the first example, an error on one item will be caught, and the loop will continue for the rest of the items.
In the second, once you hit an error, the rest of the loop will never be executed.

that depends what do you want to achieve :) first one will try every function in loop, even if one of them will fail, rest will get run... second one will abort whole loop on even one error...

In the first example, the loop is continuing after the catch occurs (unless you tell it to break). Maybe you'd want to use this in a situation where you need to collect error data into a List (something to do in the catch) to send an email to someone at the end and don't want to stop the entire process if something goes wrong.
In the second example, if you want it to hit the breaks immediately when something goes wrong so you can analyze, it will prevent the rest of the loop from happening.

You should rather look at what behaviour you want than what the performance is. Consider whether you would want the ability to continue the loop when an exception happens, and where you would do any cleaning up. In some cases you would want to catch the exception both inside and outside the loop.
A try...catch has quite small impact on performance. Most things that you do that can actually cause an exception takes a lot longer than it takes to set up for catching the exception, so in most cases the performance difference is negligible.
In any case where there would be a measurable performance difference, you would do very little work inside the loop. Usually in that case you would want the try...catch outside the loop anyway, because there isn't anything inside the loop that needs cleaning up.

The performance difference will be negligible for most applications.
However the question is do you want to keep processing the rest of the items in the loop if one fails. If yes, use the inner foreach, otherwise use the single outer loop.

How much would wrapping every method in in try-catch blocks slow a program down? [duplicate]

This question already has answers here:
Do try/catch blocks hurt performance when exceptions are not thrown?
(13 answers)
Closed 9 years ago.
So I'm working on this code base, and every single method is contained within a try-catch block, which just logs the exception to a logging file.
I'm considering waving my hands around and trying to get this changed, but I'm gone in a month, and I'm not sure how much it really slows the code down. Yeah, it's horrible practice, but that's par for the course. Yeah, it makes errors more difficult to debug, but it's "easier".
The deciding factor for people here is speed. So I'm wondering how much slower would this really make the code? I'm asking for a ballpark estimation from someone who knows compilers much better than I do.
I know there's a lot of duplicate questions about whether or not exceptions slow things down, and that it differs depending on compiler versions and the like, but I'm looking for more of a factor of/ some advice here. I'm also just plain curious.

It's probably not going to slow down the running application, since it doesn't actually do anything until an exception is thrown. (Unless you're really trying to squeeze every bit of performance, and most applications don't need to do that. Not to mention that this coding style implies very heavily that this application probably has lots of other more prevalent problems.)
What it is doing is polluting the code with tons of unnecessary exception catching. (Note the difference between catching and meaningfully handling. I can guarantee you that this code is doing the former, not the latter.) It's slowing down development, and hours of developer time is a lot more expensive than milliseconds of system time.
Yeah, it's horrible practice, but that's par for the course.
Sounds like you've already left :)
Yeah, it makes errors more difficult to debug, but it's "easier".
Those are two mutually-exclusive statements. It can't be both more difficult and easier. Someone somewhere thought it would be easier. They were mistaken.
How much would wrapping every method in try-catch blocks slow a program down?
Measured in development time, a lot.

Putting a try/catch in every method to catch the general exception ends up being a pain for reasons other than performance. Namely, the application continues to "function" regardless of the state of the application. In other words, not all Exceptions can or should be handled. E.G. What happens when the database goes down, the email server, a bad transaction (or something that should have been transactional but wasn't because poor design) etc...?
I've worked in similar environments. The concern ultimately was not one of performance. I fear places that throw around "performance reasons" as a general vague, catch-all reason to make otherwise arbritrary decisions...I digress.
However, if you are out in a month then I caution you to consider whether the argument is warranted. The development shop has proven to below your standards. It's important not to burn a bridge as a bad reference can cost you a future position.

Code within a try block is limited in how it can be optimized by the compilers. You would, in effect, limit optimizations if you wrapped every method with a try/catch. See http://msmvps.com/blogs/peterritchie/archive/2007/06/22/performance-implications-of-try-catch-finally.aspx and http://msmvps.com/blogs/peterritchie/archive/2007/07/12/performance-implications-of-try-catch-finally-part-two.aspx
The degree to which performance would be affected would be application-specific.

Performance cost of a try/catch block [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Performance Cost Of ‘try’
I am being told that adding a try catch block adds major performance cost in the order of 1000 times slower than without, in the example of a for loop of a million. Is this true?
Isn't it best to use try catch block as much as possible?

From MSDN site:
Finding and designing away
exception-heavy code can result in a
decent perf win. Bear in mind that
this has nothing to do with try/catch
blocks: you only incur the cost when
the actual exception is thrown. You
can use as many try/catch blocks as
you want. Using exceptions
gratuitously is where you lose
performance. For example, you should
stay away from things like using
exceptions for control flow.
Also see these related SO questions: (1) (2) (3) and (4).

I could swear there was a question like this just a few days ago, but I can't find it...
Just adding a try/catch block is unlikely to change the performance noticeably when exceptions aren't being thrown, although it may prevent a method from being inlined. (Different CLR versions have different rules around inlining; I can't remember the details.)
The real expense is when an exception is actually thrown - and even that expense is usually overblown. If you use exceptions appropriately (i.e. only in genuinely exceptional or unexpected error situations) then they're unlikely to be a significant performance hit except in cases where your service is too hosed to be considered "working" anyway.
As for whether you should use try/catch blocks as much as possible - absolutely not! You should usually only catch an exception if you can actually handle it - which is relatively rare. In particular, just swallowing an exception is almost always the wrong thing to do.
I write far more try/finally blocks (effectively - almost always via using statements) than try/catch blocks. Try/catch is sometimes appropriate at the top level of a stack, so that a service can keep processing the next request even if one fails, but otherwise I rarely catch exceptions. Sometimes it's worth catching one exception in order to wrap it in a different exception - basically translating the exception rather than really handling it.

You should definitely test claims like this (easy enough), but no, that isn't going to hurt you (it'll have a cost, but not 1000's of times).
Throwing exceptions and handling them is expensive. Having a try..catch..finally isn't bad.
Now with that said, If you are going to catch an exception, you need to have a plan for what you are going to do with it. There is no point in catching if you are just going to rethrow, and a lot of times, there's not much you can do if you get an exception.

Adding try catch blocks helps control your application from exceptions you have no control over. The performance cost comes from throwing an exception when there are other alternatives. For example throwing an exception to bail out of a routine instead of simply returning from a routine causes a significant amount of overhead, which may be completely unnecessary.

I am being told that adding a try
catch block adds major performance
cost in the order of 1000 times slower
than without, in the example of a for
loop of a million. Is this true?
Using try catch adds performance cost, but it isn't a major performance cost.
Isn't it best to use try catch block
as much as possible?
No, it is best to use try catch block when makes sense.

Why guess at the performance costs, when you can benchmark and see if it matters?

It's true that exceptions a very expensive operation. Also try..catch blocks clutter the code and make it hard to read. That said exceptions are fine for errors that should crash the application most of the time.
I always run on break on all exceptions, so as soon as an error happens it throws and I can pinpoint it fairly easy. If everyone is throwing exceptions all the time I get bad performance and I can't use the break on all exceptions, that's makes me sad.
IMO don't use exception for normal program events (like user types in a non-number and you try to parse it as a number). Use the normal program flow constructs for that (ie if).
If you use functions that may throw you make a choice. Is the error critical => crash the app. Is the error non-critical and likely => catch it (and potentially log it).

Using Exceptions throwing in C#. Does it affect a performance?

Basically, the question is:
Do the Exceptions in C# affect the performance a lot? Is it better to avoid Exceptions rethrow? If i generate an exception in my code, does it affect a performance?
Sorry for the sillines of the question itself

If you're worried about exception performance, you're using them wrong.
But yes, exceptions do affect performance.

Raising an exception is an expensive operation in C# (compared to other operations in C#) but not enough that I would avoid doing it.
I agree with Jared, if your application is significantly slower because of raising and throwing exceptions, I would take a look at your overall strategy. Something can probably be refactored to make exception handling more efficient rather than dismissing the concept of raising exceptions in code.

Microsoft's Design Guidelines for Developing Class Libraries is a very valuable resource. Here is a relevant article:
Exceptions and Performance
I would also recommend the Framework Design Guidelines book from Microsoft Press. It has a lot of the information from the Design Guidelines link, but it is annotated by people with MS, and Anders Hejlsberg, himself. It gives a lot of insight into the "why" and "how" of the way things are.

running code through a try/catch statement does not affect performance at all. The only performance hit comes if an exception is thrown ... because then the runtime has to unwind the stack and gather other information in order to populate the exception object.

What most other folks said, plus:
Don't use exceptions as part of the programming flow. In other words, don't throw an exception for something like, account.withdrawalAmount > account.balance. That is a business case.
The other biggie to look out for regarding performance is swallowing exceptions. It's a slippery slope, and once you start allowing your app to swallow exceptions, you start doing it everywhere. Now you may be allowing your app to throw exceptions that you don't know about because you are swallowing them, your performance suffers and you don't know why.

This is not silly just I've seen it somewhere else also on SO.
The exceptions occur well, when things are really exceptional. Most of the time you re-throw the exception (may after logging) when there are not many chances of recovering from it. So it should not bother you for normal course of execution of program.

Exceptions as its name implies are intended to be exceptional. Hence you can't expect them to have been an important target for optimisation. More often then not they don't perform well since they have other priorites such as gathering detailed info about what went wrong.

Exceptions in .NET do affect performance. This is the reason why they should be used only in exceptional cases.

How to work with unchecked exceptions?

Java has compiler checked exceptions. When I made transition to C++, I learned it doesn't feature checked exceptions. At first, I kept using exception handling, because it's a great feature. However, after a while I abandoned it, because I got into a situation every function might throw an exception. As only a small percentage of the functions I write can throw exceptions (say some 25% at the most), I found the overhead of doing exception handling for functions that cannot throw anything unacceptable.
Because of this, I am really surprised that there are a lot of developers who prefer unchecked exceptions. Therefore, I am curious to know how they handle this problem. How do you avoid the overhead of doing unnecessary exception handling in case the language doesn't support checked exceptions?
Remark: My question equally applies to C++ and C#, and probably to all other languages that don't feature compiler checked exception handling.

Simple. You don't do exception handling in "every function that might throw" - in C++, just about every function might do so. Instead, you do it at certain key points in your application, where you can produce a sensible, application-specific diagnostic and take sensible, application-specific corrective action, although use of the RAII idiom means (as avakar points out in his answer) that there is often little corrective action to be taken.

When I first started using C# I was scared by this too. Then I found that actually, it doesn't matter very often. I very rarely find that I can catch an exception and so something useful with it anyway... almost all my exceptions bubble up to somewhere near the top of the stack anyway, where they're handled by aborting the request or whatever.
Now when I'm writing Java, I find checked exceptions intensely frustrating a lot of the time. I think there's value in there somewhere, but it introduces as many problems as it solves.
Basically, I think we haven't really got the whole error handling side of things "right" yet, but on balance I prefer the C# approach to the Java approach.

In addition to what Neil said, you should note that there is no need for try/finally (or in context of C++ try/catch/throw), because object destructors are called even if an exception is thrown.
It is easily possible to have exception-safe code with very few try statements.

For C++ specifically, the overhead pretty much goes away if you design your classes well and use RAII.
Martin York has written a wonderful example of that in this answer.
The function can stll throw an exception, yes, but if it does, it won't need to do anything special to clean up. So you only need to actually catch the exception in one place -- the function that is able to handle it and recover from the error.