Develop Reference

So is it best to use try/catch? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
When is it best to use try and catch? I've gotten angry responses when I answered questions using try and catch (some even -1 me...) I Googled it and found this article and also this stackoverflow question.
I give some examples:
I have a drop down list with time zone IDs, when the user selects his time zone I'm updating the database. In other application i'm pulling this the value from the DB and recalculate the user current time and date. There is an option that the data in the DB is misspelled (hardcoded change in the DB or bug). In the conversion method of the date time of the user I'm using try and catch, which some people told me it is wrong!. I could check the value from the DB using for loop but it is costing more for each time I'm converting the date time...
I have to declare if an XML file is well formatted using this code:
protected bool IsValidXML(string xmlFile)
{
try
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(xmlFile);
}
catch(XmlException ex)
{
///write to logger
return false;
}
return true;
}
I can't see any other way to check the xml file.
Sometime I have a part on my application I'm writing to a file. writing to a file can cause exeprtion for many reasons , some other process is using this file while writing or other. so usually I'm using this code:
using (StreamWriter w = new StreamWriter(fs))
{
try
{
w.Write("** (Line) " + someValue + " **" + Environment.NewLine);
w.Flush();
}
catch(IOExeption ex){}
finally
{
w.Close();
}
}
In conclusion I see some ways to use try and catch and ways to not use. The one sentence in the article I saw said If an exception happens, you need to know about it. , but when dealing with a generic application most of the times I know that an exception will happened but most of the times I can't really know why it happened so I can't catch it before (like the examples I wrote) , So when is best to use the try and catch
In the same level in ASP.NET the page has an Error event that you can catch like so:
this.Error += new EventHandler(Page_Error); //this = instance of System.Web.UI.Page
Is the event is the same as try catch problem??

How you handle an exception depends on the nature of the exception, and on the context in which it occurs.
Smart people have written excellent articles about the subject, and I certainly can recommend:
How to Design Exception Hierarchies by Krzysztof Cwalina
Vexing exceptions by Eric Lippert
API Design Myth: Exceptions are for "Exceptional Errors" by Krzysztof Cwalina
About your examples:
In case 1 you might indeed want to be defensive. But then make sure that you do something sensible in that catch block.
Case 2 looks reasonable, but you're reading the XML document only to throw it away. Would it no make more sense to also process it?
In Case 3 you are using try finally, which is definitely not the same thing as try catch. In your specific example you don't even need it, as the using statment is already making sure the file will be closed.

From a personal perspective I've always assumed that whatever can go wrong, will go wrong and write my exception handling strategy accordingly. One of my major bugbears with others code is when you get an unhandled exception that could easily have been trapped - it looks messy an if it is production code then it shows a complete lack of knowledge of how your program works and the things that might go wrong.
My approach might be overkill, but if something you are doing can throw an error then it should be trapped. I'm not a huge fan of letting exceptions cascade through the stack and being caught at the top level - I'd prefer to trap them at source, log them and then, if the application allows it continue, or at worst fail gracefully and leave the user (or other developers) understanding what has gone wrong or why.
With web applications we use a slightly different approach. The error (stack trace etc) is logged, so that authorised people can see it and the user is given a cut-down version of the error which tells them something has gone wrong but not the specifics.
Thats my two pence anyway. I'm not sure if the approach is right or wrong, but it works for us and helps us to produce more robust code.

The criticisms of your use of try/catch in this answer were not against using try/catch in general, but against that particular way of using it.
You should capture the exception object (i.e. use catch(SomethingHappenedException e) so you get the available information about what went wrong.
You should catch specific exceptions rather than everything. In the DateTime example, I would try to find what exceptions might be thrown by each of my calls. I would then try and figure out if there was some way of trapping these errors without using exceptions - one of the exceptions that might be caught in that code is a ArgumentNullException. That's an exception, but I should be able to handle that within the flow by first checking that I'm not passing a null zone id.
Finally, if it's not possible to handle those cases within the normal flow of the program, I catch specific exceptions that might plausibly occur, and as closely to the source of the exception as possible.
It might seem a bit more effort but it does save you on debugging time down the road!

For example 1, it would be helpful to see code. It's hard to comment without a more concrete idea of what you're doing.
For example 2, the problem with that code is that it completely hides any error condition. Sure, we'll find out if an xml file is good or bad... but why is the xml good or bad? We can't know. It's not that try/catch is bad: it's that the whole thing is being written at the wrong level. Just write code to read the xml file, and have your error handling around that code.
For example 3, you are again swallowing any helpful exception information, and in fact not doing anything with your try/catch at all. The .Close() call in your finally blocks is completely unecessary, because closing your stream is entirely handled when the stream is disposed by the using block.
In summary, I think what you need to learn here is not that try/catch blocks are bad. It's that swallowing exception information is bad.

I think I can sum up the issues people have had in the past with your questions on try...catch, as well as provide some clarity that should help you in the future.
Your first two examples are caused by data validation errors. The data should be checked for known validation errors before being passed to the conversion function (example 1) or trying to write an XML file (example 2).
There is significant overhead in exception handling, so it should only occur when absolutely necessary. The try...catch pattern is designed for handling unexpected (exceptional) errors, not standard data validation.
Example 3 is almost proper usage. It is a situation where there are unexpected things that may occur that you cannot be prepared for, like an IOException. Catching a specific exception is considered bad form as it can lead to multiple catch blocks or missed handling. Catching the generic Exception object is better, and the exception handling code can determine and deal with the exact type of exception.
Your try...catch block should encapsulate the streamwriter as well, since it is best practice to only have one try...catch per method. If you use try...catch, it must always contain exception handling code. Empty catch blocks or empty finalize blocks are bad form and are not helping the code or anyone who is trying to maintain it after you.
try
{
using (StreamWriter w = new StreamWriter(fs))
{
w.Write("** (Line) " + someValue + " **" + Environment.NewLine);
w.Flush();
}
}
catch(Exception ex)
{
//exception handling code here
}
finally
{
//any clean up code here. The using statement makes it unnecessary for the streamwriter
}
Hope all of this helps answer some questions and bring some clarity to the issue.

In my experience, any external operations (such as interacting with a db or file system, or using 3rd party components) should have a try catch block around it. In my own code, I always try to put in guard clauses to methods to limit the number of exceptions my own code produces, if for example you know that the database won't accept a null First name on a person object, add a guard clause should be added to the top of any save method.
In short, don't rely on exceptions to tell you where your code is going wrong, rather try to cut down the likelyhood of an exception first

If try-catch can be replaced by if-then-else, which one is recommended?

In my rough investigation, I think any errors can be handled by using if-then-else construct. Let's take a simple example as follows.
Division by zero can be handled with
int x=1;
int y=0;
if(y==0)
Console.WriteLine("undefined");
else
Console.WriteLine("x/y={0}",x/y);
to replace the try-catch equivalent
int x=1;
int y=0;
try
{
Console.WriteLine("x/y={0}",x/y);
}
catch
{
Console.WriteLine("undefined");
}
If try-catch can be replaced by if-then-else, which one is recommended?

You should never use exceptions for flow of control.
Exceptions should be "exceptional". If you know the rules for some data validation, you should use normal if/then/elses.
If you are doing some operation that can go wrong multiple ways (like connecting to a db) you should put that operation into a try-catch block and act accordingly.
Alas, the choice to treat something as "exceptional" goes into the designer's judgement.
EDIT: Also, do not underestimate the power of logging. Since I started using logging frameworks, my debugging time got cut by half.

Not all errors for the simple reason that there are some unexpected errors and this is where you want to use a try-catch statement. However, it isin't a good practice to use try-catch for things that you can prevent going wrong.
Additionnaly, I would only catch exceptions that I know how to handle or that can be handled, otherwise you will be blindly swallowing every exceptions and your application will be extremely hard to debug.
However, if you don't know how to handle an exception but you know that your application can recover from an error in that portion of code and want to avoid your application to crash because of an unhandled exception, it could by fine to use a try-catch block, but it would also be a good idea to log the exception details.

The try-catch block is the most efficient measure when it comes to Exception Handling. Here in this you are talking about a very simple and basic example, but there are lot many cases in the programming when there are multiple errors or exceptionn that could be found to a single expression. It is always prefer to go with (try-catch) block instead of checking for each condition.

Because you don't alawys simply want to communicate an error by simply spewing data to the console. That is usually the course of last resort.
typically, you want to develop a structured error handling system. One notable featured of a structured system like this is is the ability to communicate an error condition to the caller of a function or procedure. in this instance if the caller is aware that there may be esceptional circumstances and is prepared to deal with this error communication from the callee, it is done so.
howeer, exception have a special property , that they will continue to exist as long as they are uncaught, going further and further back up the chain of callers until the 'signal' , the error, they represent is handled.
many times, errors ( exceptions ) ARE caught and dealt with ( handled ) without sending anything to the console.
The up-chaining, propagating exception system provides a baked-in-the-compiler , syntactically clean way of providing structured error handling.
error codes or signals can also be used for this purpose, but are not quite as syntactically smooth, and leave a lot of traces in the coding, of there being a lot of error handling code. Exceptions try to hide error handling, except where it is absolutely necessary, by using the compiler and runtime to keep track of error code status automatially.

You can use both.
Without try catch it is hard to find what specific error your code throws.
try
{
int x=1;
int y=0;
if(y==0)
Console.WriteLine("undefined");
else
Console.WriteLine("x/y={0}",x/y);
}
catch
{
Console.WriteLine("undefined");
}
Best Regards

I wanted to add to this another important reason why in C# and many languages it's bad practice.
It's slow!
I had a situation where I was using try catch for flow control early on and it took about 15 ms to process the catch, where when I re-wrote it into a if-then statement it only took 1 ms when it hit the else (the catch). Some other languages are very efficient at try catch such as python and can use them in unique ways that C# should never do.

try catch is efficient in large or small codes because when you put your code that you think maybe error occurred in this section of code . and then you catch the exceptions of your code if it occurred in run time. and if you want run a line of code that is important for running like you want to call GC or handle your memory allocation and free it and etc, you can put these codes in finally section and its completely support all type of code .and its a good way for exception handling.
try{code that you think maybe error occurred }
catch {if error or exception occurred how handle it }
finally{all code that you want run when program has exception or has not }

The try catch in your case does not process the same logic as your if statement. You just implicitly assume it does. y == 0 is totally different from assuming that the only error which might occur is when y is 0.
So basically a programmer does not know for sure what might cause the branching code.
See also this article, which states, that using try-catch for flow control violates the 'principle of least astonishment': Why not use exceptions as regular flow of control?

The block TRY..CATCH does not replace IF..ELSE! They are two diffeent things.
The TRY..CATCH block catches errors, if ever there is one, whereas the IF..ELSE is a condition. If the 1st condition is false, it'll execute the ELSE part.
The best practice however would be to use the two;
try
{
if(y==0)
{
Console.WriteLine("undefined");
}
else
{
Console.WriteLine("x/y={0}",x/y);
}
}
catch (Exception ex)
{
Console.WriteLine("Error" + ex);
}
In this case here, if y was declared as Date for example, the condition would throw an error as (y==0) won't be evaluated. Thus sending you to the CATCH, which will throw you the conversion type error.
On the other hand, if y is declared as int (as in your example), there's not error evaluating (y==0) and hence, the IF..ELSE block will be executed.

Using Try/Catch block is the best way since through exception management we can LOG these errors into any file OR we can throw this exception to the parent function within the application. Also any new programmer also can understand the code more clearly since you have used try/catch blocks.
Thanks,
Skyrim.

I miss Visual Basic's "On Error Resume Next" in C#. How should I be handing errors now?

In Visual Basic I wrote just On Error Resume Next in the head of my program and errors were suppressed in the entire project.
Here in C# I miss this feature very much. The usual try-catch handling for every single procedure is not only very time-intensive, it brings undesired effects. If an error is encountered, even if handled, the code doesn't continue from the point it occurred. With On Error Resume Next, the code continued from the point of error, skipping just the function call that caused the error.
I am not deeply involved with C# yet, but maybe there exists in C# a better error handling than the primitive try-catch.
I also would like to have the module or function name where the error occured as well as the the line number in my error message. The Exception class doesn't provide that features as far I know. Any ideas (managed, of course, without involving any process classes on my own application)?
How do you handle the errors in bigger projects? I hope I do not have to add a try-catch to each method. Somehow C# throws many errors - that seems to be typical of the language.
My Solution which I found to re-solve several of my problems:
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
[STAThread]
static void Main()
{
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException); //setup global error handler
Application.Run(new Form1());
}
private static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
MessageBox.Show("Unhandled exception: " + e.Exception.ToString()); //get all error information with line and procedure call
Environment.Exit(e.Exception.GetHashCode()); //return the error number to the system and exit the application
}
private void button1_Click(object sender, EventArgs e)
{
string s = ""; s.Substring(1, 5); //Produce an error
}
}

Continuing after errors as if nothing's happened is a terrible way of programming.
Can't work out the new balance of the account? That's okay, let's just store it as 0. No-one will ever know, right?
try/catch blocks should actually be relatively rare, because there are relatively few errors you can really recover from. Typically you should have one try/catch block at the top of some logical operation, so that if it fails you can inform the user and continue with other entirely separate operations - or terminate the app completely, depending on the kind of application you're writing. (Web apps are a good example here: you can fail the request, hopefully taking care that you don't have nasty persistent side-effects, and continue to handle other requests.)
Where there are places you legitimately expect errors you can recover from, catch those specific exceptions and handle them appropriately (e.g. falling back to writing to a file if writing to a database fails). Again, these are relatively few and far between. If you find yourself writing a try/catch block in every method (or even every class) then you're probably handling exceptions inappropriately.
I also would like to have the module or function name where the error occured as well the line number in my error message. The Exception class doesn't provide that features as far I experienced.
Yes it does. The stack trace shows the type, method and line number (where available) for each frame in the stack... as well as a (hopefully useful) message, of course. Oh, and potentially a nested exception too, if one failure was caused by another.
Somehow C# throws many errors on execution always, that's language typical.
Nope, that just suggests you're Doing It Wrong.

No.
Speaking as an ex-VB programmer, please let me assure you: that is the worst and most abused feature ever added to any language ever. Here's the idea instead:
write code that doesn't error ... unless something happens that is actually a problem. This may involve checking your assumptions before you do things; great: do that
only catch problems you were expecting; swallowing all errors is just asking for massive problems
As already noted by Jon, it is actually pretty rare to need exception handling all over the place. Usually you just let an exception bubble up to a higher caller, because something bad just happened. And when I do have a try, it is more commonly try/finally (not try/catch) - with using and lock (etc) being special-cases of those for convenience.

No, you can't. This is not possible in C# (and should not be in any other language).
The true use for this in VB was to make error handling in some part of the code, just like try / catch. You enable it, check with Err.Number <> 0, do your work and restore the error flow with On Error GoTo 0 or redirect to a label that follows a different path to treat the error or continue the execution On Error GoTo someErrorCase:.
You must have learned to program alone or with a person that doesn't do it the right way. Ignoring errors is a bad habit, and more than this, its an horrible thing to just follow with code. After all, errors are possible.
Trust me. I was a VB programmer and it was enlightening when I've stopped to read on best practices.
Just to add some more, try to use Option Explicit too, it may sound more work on declaring all variables, but it will give you more confidence of the code, because the type check will constrain some common errors.
Also, C# exceptions are kind of very usefull and have all info you may want. If you haven't got the problem with the exception itself, just open it and look in its inner exception (I catch me always looking the inner exceptions when developing for web, since all code is at higher level).

Actually, exceptions are rather the exception, they don't happen all the time. When they do happen, you want to know they happened, and either handle them or shut down your process. Most of the times letting an exception go unhandled is going to lead to very unexpected results.

You have been using that VB feature wrong, and you are so lucky that you can't use it like that in C#.
When using the feature in VB you are supposed to check the error status after every operation that could result in an error. When used correctly, it's not less code than having try...catch blocks around every operation that could result in an error.
So, if you think that you have to do more error handling in C#, you have been doing far too little error handling before.

"On Error Resume Next" allows for "Inline Error Handling", which is the expert level error handling in VB. The concept is to handle errors line by line, either performing an action based on the error or ignoring the error when beneficial - but running code in the sequence in which it is written and not using code jumps.
Unfortunately, many novices used "On Error Resume Next" to hide either their lack of ability or out of laziness from those using their applications by ignoring all errors. Try/catch is block level error handling, which in the pre-.NET world was intermediate by design and implementation.
The problem with "On Error Resume Next" in VB.NET is that it loads the err object on every line of executing code and is, therefore, slower than try/catch.
https://msdn.microsoft.com/en-us/library/aa242093(v=vs.60).aspx
It being said that intermediate C# programmers with no real VB experience shouldn't try to keep C# dumbed down and feature limited because of their weird disdain for another "Microsoft Net" language, Consider the following code:
//-Pull xml from file and dynamically create a dataset.
string strXML = File.ReadAllText(#"SomeFilePath.xml");
StringReader sr = new StringReader(strXML);
DataSet dsXML = new DataSet();
dsXML.ReadXml(sr);
string str1 = dsXML.Tables["Table1"].Rows[0]["Field1"].ToString();
string str2 = dsXML.Tables["Table2"].Rows[0]["Field2"].ToStrin();
string str3 = dsXML.Tables["Table3"].Rows[0]["Field3"].ToStrin();
string str4 = dsXML.Tables["Table4"].Rows[0]["Field4"].ToString();
string str5 = dsXML.Tables["Table5"].Rows[0]["Field5"].ToString();
If the xml usually has a value for Field3 but sometimes not; I'm going to get an annoying error that the table doesn't contain the field. I could care a less if it doesn't because it's not required data. In this case, ON Error Resume Next would allow me to just ignore the error and I wouldn't have to code around each line of code setting the variables checking for the existence of the table, row and column combination with Contains methods. This is a small example; I might pull in thousands of table, column, row combinations from large files. Also, assume here that the string variables must be populated this way. This is unhandled code and there will be trouble.
Consider a VB.NET and ON Error Resume Next Implementation:
On Error Resume Next
Dim strXML As String = File.ReadAllText("SomeNonExistentFileCausingAnErrorCondition.xml")
If String.IsNullOrEmpty(strXML) Then
strXML = strSomeOtherValidXmlThatIUseWhenTheFileIsEmpty
End If
Dim srXmL As StringReader = New StringReader(strXML)
Dim dsXML As DataSet = New DataSet()
dsXML.ReadXml(srXmL)
If Err.Number <> 0 Then
MsgBox(Err.Number & Space(1) & Err.Description)
Exit Sub
End If
Dim str1 As String = dsXML.Tables("Table1").Rows(1)("Field1").ToString()
Dim str2 As String = dsXML.Tables("Table2").Rows(2)("Field2").ToString()
Dim str3 As String = dsXML.Tables("Table3").Rows(3)("Field3").ToString()
Dim str4 As String = dsXML.Tables("Table4").Rows(4)("Field4").ToString()
In the above code, it was only necessary to handle one possible error condition; even though there was an error loading the file. On Error Resume Next actually allowed me to resume as intended, which allowed me to check the string condition and use my alternate string (I'm well aware that I could have checked to the existence of the file also and avoided the file error but if it were a good file with nothing in it, strXML would be an empty string). The error that was critical to the rest of the code was handled and the method was exited because the loaded dataset was paramount for the rest of the processing beyond it (processing that could be run through ignoring any errors if desired). The file error could be ignored as I ignored it or I could have checked the error condition and logged it.
RAD development needs On Error Resume Next. C# is my choice of languages but it isn't as much a RAD language as VB for many reasons. I hope all programmers realize that several major languages (i.e. C) just run and don't halt execution on unhandled errors; it's the developers job to check for them where they think necessary. On Error Resume Next is the closest thing to that paradigm in the Microsoft world.
Luckily, .NET does give many advanced choices to handle these situations; I eluded to the Contains. So, in C#, you have to beef up your knowledge level of the language and you properly, according to the C# language specification, work around such issues. Consider a solution for handling a large block of repetitive lines of code that could contain an annoying throw away error:
try
{
if (!File.Exists(#"SomeFilePath.xml")) { throw new Exception("XML File Was Not Found!"); }
string strXML = File.ReadAllText(#"SomeFilePath.xml");
StringReader sr = new StringReader(strXML);
DataSet dsXML = new DataSet();
dsXML.ReadXml(sr);
Func<string, string, int, string> GetFieldValue = (t, f, x) => (dsXML.Tables[t].Columns.Contains(f) && dsXML.Tables[t].Rows.Count >= x + 1) ? dsXML.Tables[t].Rows[x][f].ToString() : "";
//-Load data from dynamically created dataset into strings.
string str1 = GetFieldValue("Table1", "Field1", 0);
string str2 = GetFieldValue("Table2", "Field2", 0);
string str3 = GetFieldValue("Table3", "Field3", 0);
//-And so on.
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
Although in a try/catch block, the lambda function is checking for the existence of every table, row, column combination that is being pulled from the dataset that was populated dynamically by the xml. This could be checked line by line but would require a lot of excess code (here we have the same amount of executing code but far less written code to maintain). This unfortunately might be considered another bad practice of "One Line Functions." I break that rule in the case of lambdas and anonymous functions.
Since .NET offers so many ways to check the status of objects; On Error Resume Next isn't as vital to VB experts as it was prior to .NET but still nice to have around; especially when you're coding something that would be a waste of time to not code fast and dirty. No one who has ever used VB on an expert level would ever claim that On Error Resume Next (inline error handling) is the worst feature ever added to a language. However, it has been widely misused by novices.

Exceptions vs return codes : do we lose something (while gaining something else)?

My question is pretty vague :o) - But here is an example :
When I was writing C code, I was able to log counter's value when something failed :
<...>
for ( int i = 0 ; i < n ; i++ )
if ( SUCCESS != myCall())
Log( "Failure, i = %d", i );
<...>
Now, using exceptions, I get this :
try
{
<...>
for ( int i = 0 ; i < n ; i++ )
myCall();
<...>
}
catch ( Exception exception )
{
Log( "Failure ! Maybe in myCall() ? Don't know. i's value ? No clue." );
}
Of course, one may declare "i" outside of the try/catch statement (and this is what I'm doing). But I don't like it - I like declare variable where they are used, not before.
But maybe am I missing something here. Do you have any elegant solution ?
Thank in advance !
Sylvain.
ADDED : myCall() is an obscure API call - I have no clue what it can throw. Also, I can of course add a Try/Catch block around each call, but I would then be better to use return codes ? Would I then add a lot of noise around important lines of code ?.

how about:
for(int i = 0; i < n; i++)
{
try
{
myCall();
}
catch(Exception e)
{
Log(String.Format("Problem with {0}", i));
}
}

I think you've got it wrong, and its not surprising as many other people do too.
Exceptions are not to be used for program flow. Read that again, its important.
Exceptions are for the "whoo, that's wasn't supposed to happen" errors that you hope never to see at runtime. Obviously you will see them the moment your first user uses it, which is why you have to consider the cases where they might happen, but you should still not try to put code in to catch, handle and continue as if nothing had happened.
For errors like that, you want error codes. If you use exceptions as if they were 'super error codes' then you end up writing code like you mentioned - wrapping every method call in a try/catch block! You might as well return an enum instead, its a lot faster and significantly easier to read error return code than litter everything with 7 lines of code instead of 1. (its also more likely to be correct code too - see erikkallen's reply)
Now, in the real world, it is often the case that methods throw exceptions where you'd rather they didn't (EndOfFile for example), in which case you have to use the "try/catch wrapper" anti-pattern, but if you get to design your methods, don't use exceptions for day-to-day error handling - use them for exceptional circumstances only. (yes, I know its difficult to get this kind of design right, but so is much of design work)

I don't like the "now, with exceptions..." expression.
Exceptions are a tool that you have for using it in your programming - if you think that it is the best option, use it, otherwise, don't.
I follow a personal rule of not throw any exceptions that I can avoid throwing, in internal code. For an API of a publicly available DLL, precondition checks should be left enabled and trigger exceptions if they fail, yes; but for internal logic, I seldom (if ever) include exceptions in my design. Conversely, when I'm using some function that documents that it will throw if some bad situation happens, I tend to capture the exception inmediately - it is an expected exception, after all.
If you think that your non-exceptional alternative is better - stick to it!

Yeah. 2 things.
Put the try-catch blocks where they make sense. If you're interested in exceptions from myCall (as well as i's value) then use
for ( int i = 0 ; i < n ; i++ )
try { myCall(); } catch ( Exception exception ) {
Log( "Failure, i = %d", i );
}
Throw objects of different classes for different errors. If you're interested in logical errors occurring in financial processing, throw finances::logic_error, not std::exception("error msg") or something. This way you can catch what you need.

Two things here, from my perspective.
It's not outrageous to expect the exception itself to contain information about the value of i, or less specifically about the context it was evaluated in and what went wrong. For a trivial example, I would never just throw a straight InvalidArgumentException; rather, I would ensure I passed an accurate description into the constructor, such as
public void doStuff(int arg) {
if (arg < 0) {
throw new InvalidArgumentException("Index must be greater than or equal to zero, but was " + arg);
}
...
This might not expilictly log the value of i, but in most cases you're going to be able to understand what the problem was with your input that caused the error. This is an argument in favour of exception chaining too - if you catch, wrap and rethrow exceptions at every conceptual level, then each wrapping can add its own relevant variables that are too high up to be seen or understood by the fundamental low-level error.
Alternatively, if things are really too abstracted for your myCall function to know what is going on, then I find that logging at a higher verbosity level before making the call works well, e.g.
try
{
<...>
for ( int i = 0 ; i < n ; i++ )
DebugLog("Trying myCall with i = " + i);
myCall();
<...>
}
catch ( Exception exception )
{
Log( "Failure ! Maybe in myCall() ? Don't know. i's value ? No clue." );
}
This way, if something does go wrong you can inspect your high-verbosity debug log and find what i was just before the call that threw the exception.

Consider the opinions of Raymond Chen as well as Microsoft's x64-thinking.
(( raymond chen exceptions )) as a Google-query is enough to get you to his classic essays "Cleaner, more elegant, and wrong -- Just because you can't see the error path doesn't mean it doesn't exist." and the clarification "Cleaner, more elegant, and harder to recognize".
(( x64 exception model )) gets you to the MSDN article "Everything You Need To Know To Start Programming 64-Bit Windows Systems", which contains the quote "The downside to table-based exception handling (relative to the x86 stack-based model) is that looking up function table entries from code addresses takes more time than just walking a linked list. The upside is that functions don't have the overhead of setting up a try data block every time the function executes."
To summarize this quote, in x64 it is free or nearly-free to setup a "catch" which is never used, but to actually throw-catch an exception is slower than in x86.

It can be more elegant, if the object that you throw, can hold the context information that tells you something about the nature of the error.
Derive a throwable object from an istream, and you can use >> to stream information into it.
teach the object how to display itself <<.
When you detect an error condition, in the level below, or N levels below. Fill up your object with good context information, and throw it. When you catch the object, tell it to display its context information to the log file, and/or the screen and/or whereever you want it to.

Of course, one may declare "i" outside of the try/catch statement (and this is what I'm doing).
Well … if you really need to know the value of i then this seems like a logging vehicle – structured exception handling probably isn't the best way then. If you want to handle the exception conditionally (i.e. only when debugging), put the try block inside the loop. Since this may hurt performance (depending on your environment), only do this in debug mode.

First things, first. If you are trapping Exception you are wrong. You should be trapping the specific exception you are expecting.
But that aside, if your exceptions are being thrown by your own code, you can use intelligent exceptions to encompass all the data you need to know about that exception.
For instance, an ArrayIndexOutOfBoundsException will contain the index addressed.

You can get more specific information in two ways. First, don't catch Exception, catch a specific exception. Second, use multiple try/catch statements in a function where you need to be sure which function call threw the exception.

In my opinion, exceptions shouldn't be used in such a case, but if you really need them, I'd go the following way:
You could pass the 'i' as a parameter to the myCall(); function and if any error occured, some special exception would be thrown. Like:
public class SomeException : Exception
{
public int Iteration;
public SomeException(int iteration) { Iteration = iteration; }
}
The loop block:
try
{
for(int i = 0; i < n; ++i)
{
myCall(i);
}
}catch(SomeException se)
{
Log("Something terrible happened during the %ith iteration.", se.Iteration);
}
And finally the myCall() function:
void myCall(int iteration)
{
// do something very useful here
// failed.
throw new SomeException(iteration);
}

We lose the possibility to easily see how the code will handle failures in different places. Raymond Chen has written a good article about it

Well! you could do this:
try
{
<...>
for ( int i = 0 ; i < n ; i++ )
try {
myCall();
} catch(Exception e) {
println("bloody hell! " + i);
}
<...>
}
I think Exceptions are cooler than Java shows it to you. What is really fun is to have the debugger come up on every exception that isn't handled and then take a look at the stack at the moment of failure, so that you can examine i without having to change a line of code. That is, I believe, what exceptions should be for.

Many exception handling tools (MadExcept for Delphi is one) allow you to retrieve the entire stack trace when you catch the exception. So, you'd know exactly where it was thrown.
The common technique for getting "i" is to catch the exception, and add extra data to it (the istream technique) before rethrowing it. It's rare that this is necessary, but if you insist...

Try-catch every line of code without individual try-catch blocks

I do not currently have this issue, but you never know, and thought experiments are always fun.
Ignoring the obvious problems that you would have to have with your architecture to even be attempting this, let's assume that you had some horribly-written code of someone else's design, and you needed to do a bunch of wide and varied operations in the same code block, e.g.:
WidgetMaker.SetAlignment(57);
contactForm["Title"] = txtTitle.Text;
Casserole.Season(true, false);
((RecordKeeper)Session["CasseroleTracker"]).Seasoned = true;
Multiplied by a hundred. Some of these might work, others might go badly wrong. What you need is the C# equivalent of "on error resume next", otherwise you're going to end up copying and pasting try-catches around the many lines of code.
How would you attempt to tackle this problem?

public delegate void VoidDelegate();
public static class Utils
{
public static void Try(VoidDelegate v) {
try {
v();
}
catch {}
}
}
Utils.Try( () => WidgetMaker.SetAlignment(57) );
Utils.Try( () => contactForm["Title"] = txtTitle.Text );
Utils.Try( () => Casserole.Season(true, false) );
Utils.Try( () => ((RecordKeeper)Session["CasseroleTracker"]).Seasoned = true );

Refactor into individual, well-named methods:
AdjustFormWidgets();
SetContactTitle(txtTitle.Text);
SeasonCasserole();
Each of those is protected appropriately.

I would say do nothing.
Yup thats right, do NOTHING.
You have clearly identified two things to me:
You know the architecture is borked.
There is a ton of this crap.
I say:
Do nothing.
Add a global error handler to send you an email every time it goes boom.
Wait until something falls over (or fails a test)
Correct that (Refactoring as necessary within the scope of the page).
Repeat every time a problem occurs.
You will have this cleared up in no time if it is that bad. Yeah I know it sounds sucky and you may be pulling your hair out with bugfixes to begin with, but it will allow you to fix the needy/buggy code before the (large) amount of code that may actually be working no matter how crappy it looks.
Once you start winning the war, you will have a better handle on the code (due to all your refactoring) you will have a better idea for a winning design for it..
Trying to wrap all of it in bubble wrap is probably going to take just a long to do and you will still not be any closer to fixing the problems.

It's pretty obvious that you'd write the code in VB.NET, which actually does have On Error Resume Next, and export it in a DLL to C#. Anything else is just being a glutton
for punishment.

Fail Fast
To elaborate, I guess I am questioning the question. If an exception is thrown, why would you want your code to simply continue as if nothing has happened? Either you expect exceptions in certain situations, in which case you write a try-catch block around that code and handle them, or there is an unexpected error, in which case you should prefer your application to abort, or retry, or fail. Not carry on like a wounded zombie moaning 'brains'.

This is one of the things that having a preprocessor is useful for. You could define a macro that swallows exceptions, then with a quick script add that macro to all lines.
So, if this were C++, you could do something like this:
#define ATTEMPT(x) try { x; } catch (...) { }
// ...
ATTEMPT(WidgetMaker.SetAlignment(57));
ATTEMPT(contactForm["Title"] = txtTitle.Text);
ATTEMPT(Casserole.Season(true, false));
ATTEMPT(((RecordKeeper)Session["CasseroleTracker"]).Seasoned = true);
Unfortunately, not many languages seem to include a preprocessor like C/C++ did.
You could create your own preprocessor and add it as a pre-build step. If you felt like completely automating it you could probably write a preprocessor that would take the actual code file and add the try/catch stuff in on its own (so you don't have to add those ATTEMPT() blocks to the code manually). Making sure it only modified the lines it's supposed to could be difficult though (have to skip variable declarations, loop constructs, etc to that you don't break the build).
However, I think these are horrible ideas and should never be done, but the question was asked. :)
Really, you shouldn't ever do this. You need to find what's causing the error and fix it. Swallowing/ignoring errors is a bad thing to do, so I think the correct answer here is "Fix the bug, don't ignore it!". :)

On Error Resume Next is a really bad idea in the C# world. Nor would adding the equivalent to On Error Resume Next actually help you. All it would do is leave you in a bad state which could cause more subtle errors, data loss and possibly data corruption.
But to give the questioner his due, you could add a global handler and check the TargetSite to see which method borked. Then you could at least know what line it borked on. The next part would be to try and figure out how to set the "next statement" the same way the debugger does it. Hopefully your stack won't have unwound at this point or you can re-create it, but it's certainly worth a shot. However, given this approach the code would have to run in Debug mode every time so that you would have your debug symbols included.

As someone mentioned, VB allows this. How about doing it the same way in C#? Enter trusty reflector:
This:
Sub Main()
On Error Resume Next
Dim i As Integer = 0
Dim y As Integer = CInt(5 / i)
End Sub
Translates into this:
public static void Main()
{
// This item is obfuscated and can not be translated.
int VB$ResumeTarget;
try
{
int VB$CurrentStatement;
Label_0001:
ProjectData.ClearProjectError();
int VB$ActiveHandler = -2;
Label_0009:
VB$CurrentStatement = 2;
int i = 0;
Label_000E:
VB$CurrentStatement = 3;
int y = (int) Math.Round((double) (5.0 / ((double) i)));
goto Label_008F;
Label_0029:
VB$ResumeTarget = 0;
switch ((VB$ResumeTarget + 1))
{
case 1:
goto Label_0001;
case 2:
goto Label_0009;
case 3:
goto Label_000E;
case 4:
goto Label_008F;
default:
goto Label_0084;
}
Label_0049:
VB$ResumeTarget = VB$CurrentStatement;
switch (((VB$ActiveHandler > -2) ? VB$ActiveHandler : 1))
{
case 0:
goto Label_0084;
case 1:
goto Label_0029;
}
}
catch (object obj1) when (?)
{
ProjectData.SetProjectError((Exception) obj1);
goto Label_0049;
}
Label_0084:
throw ProjectData.CreateProjectError(-2146828237);
Label_008F:
if (VB$ResumeTarget != 0)
{
ProjectData.ClearProjectError();
}
}

Rewrite the code. Try to find sets of statements which logically depend on each other, so that if one fails then the next ones make no sense, and hive them off into their own functions and put try-catches round them, if you want to ignore the result of that and continue.

This may help you in identifing the pieces that have the most problems.
# JB King
Thanks for reminding me. The Logging application block has a Instrumentation Event that can be used to trace events, you can find more info on the MS Enterprise library docs.
Using (New InstEvent)
<series of statements>
End Using
All of the steps in this using will be traced to a log file, and you can parse that out to see where the log breaks (ex is thrown) and id the high offenders.
Refactoring is really your best bet, but if you have a lot, this may help you pinpoint the worst offenders.

You could use goto, but it's still messy.
I've actually wanted a sort of single statement try-catch for a while. It would be helpful in certain cases, like adding logging code or something that you don't want to interrupt the main program flow if it fails.
I suspect something could be done with some of the features associated with linq, but don't really have time to look into it at the moment. If you could just find a way to wrap a statement as an anonymous function, then use another one to call that within a try-catch block it would work... but not sure if that's possible just yet.

If you can get the compiler to give you an expression tree for this code, then you could modify that expression tree by replacing each statement with a new try-catch block that wraps the original statement. This isn't as far-fetched as it sounds; for LINQ, C# acquired the ability to capture lambda expressions as expression trees that can be manipulated in user code at runtime.
This approach is not possible today with .NET 3.5 -- if for no other reason than the lack of a "try" statement in System.Linq.Expressions. However, it may very well be viable in a future version of C# once the merge of the DLR and LINQ expression trees is complete.

Why not use the reflection in c#? You could create a class that reflects on the code and use line #s as the hint for what to put in each individual try/catch block. This has a few advantages:
Its slightly less ugly as it doesn't really you require mangle your source code and you can use it only during debug modes.
You learn something interesting about c# while implementing it.
I however would recommend against any of this, unless of course you are taking over maintance of someelses work and you need to get a handle on the exceptions so you can fix them. Might be fun to write though.

Fun question; very terrible.
It'd be nice if you could use a macro. But this is blasted C#, so you might solve it with some preprocessor work or some external tool to wrap your lines in individual try-catch blocks. Not sure if you meant you didn't want to manually wrap them or that you wanted to avoid try-catch entirely.
Messing around with this, I tried labeling every line and jumping back from a single catch, without much luck. However, Christopher uncovered the correct way to do this. There's some interesting additional discussion of this at Dot Net Thoughts and at Mike Stall's .NET Blog.
EDIT: Of course. The try-catch / switch-goto solution listed won't actually compile since the try labels are out-of-scope in catch. Anyone know what's missing to make something like this compile?
You could automate this with a compiler preprocess step or maybe hack up Mike Stall's Inline IL tool to inject some error-ignorance.
(Orion Adrian's answer about examining the Exception and trying to set the next instruction is interesting too.)
All in all, it seems like an interesting and instructive exercise. Of course, you'd have to decide at what point the effort to simulate ON ERROR RESUME NEXT outweighs the effort to fix the code. :-)

Catch the errors in the UnhandledException Event of the application. That way, unhandled execptions can even be logged as to the sender and whatever other information the developer would reasonable.

Unfortunately you are probably out of luck. On Error Resume Next is a legacy option that is generally heavily discouraged, and does not have an equivalent to my knowledge in C#.
I would recommend leaving the code in VB (It sounds like that was the source, given your specific request for OnError ResumeNext) and interfacing with or from a C# dll or exe that implements whatever new code you need. Then preform refactoring to cause the code to be safe, and convert this safe code to C# as you do this.

You could look at integrating the Enterprise Library's Exception Handling component for one idea of how to handle unhandled exceptions.
If this is for ASP.Net applications, there is a function in the Global.asax called, "Application_Error" that gets called in most cases with catastrophic failure being the other case usually.

Ignoring all the reasons you'd want to avoid doing this.......
If it were simply a need to keep # of lines down, you could try something like:
int totalMethodCount = xxx;
for(int counter = 0; counter < totalMethodCount; counter++) {
try {
if (counter == 0) WidgetMaker.SetAlignment(57);
if (counter == 1) contactForm["Title"] = txtTitle.Text;
if (counter == 2) Casserole.Season(true, false);
if (counter == 3) ((RecordKeeper)Session["CasseroleTracker"]).Seasoned = true;
} catch (Exception ex) {
// log here
}
}
However, you'd have to keep an eye on variable scope if you try to reuse any of the results of the calls.

Hilite each line, one at a time, 'Surround with' try/catch. That avoids the copying pasting you mentioned