If I put empty catch blocks for my C# code, is it going to be an equivalent for VB.NET's "On Error Resume Next" statement.
try
{
C# code;
}
catch(exception)
{
}
The reason I am asking this is because I have to convert a VB.NET code to C#, and the old code has ~200 "On Error Resume Next" statements although I am using a proper try {} catch {}
in my new code, but is there is a better alternative?
Using "On Error Resume Next" is not a good idea for error handling (of course, this is my personal opinion, but seems that most of the developers agree with me though). As other guys advised you in previous posts, use
Try...Catch...Finally
(whether in VB.NET or C#).This is a very smart option for error handling, but it will also allow you to do nothing with the error (an empty catch block) :) I would suggest you to put every line of code (which may cause error) in separate
Try...Catch Block
, so that you would have the opportunity to do whatever you want if an error occurs. Happy Coding guys :)I am an old hat at VB6. First a short lesson...
There are reasons to use On Error Resume Next. Mostly for readability. In VB6 you have two ways to implement Error trapping. You can use an "inline" On Error Resume Next like this.
Or, you may see this:
But in old VB6 code you will likely also see this...
Regardless it is pretty straight forward to convert these cases into Try Catch... If you need to sink an error use a quick "inline" looking On Error Resume Next just do this..
You can also raise the try catch to the calling routine, by encapsulating the code into a subroutine... So if you need to sink the entire subroutine do this...
Do this in the case where PerformAction() subroutine contains an On Error Resume Next at the top of the code, use the Try Catch in the calling subroutine
Good luck...
I happen to think those people who invented "On Error Resume Next" did have something in mind when they created it. The answer to your question would be no, there's nothing equivalent to this construct in C#. We have in C# and .Net a lot of functions that are so hungry for care and attention it gets tiring after a while to cater to everybody's "exceptional behavior". When almost everything can throw an exception the word itself looses it's meaning somewhat. You're inside an iteration and what should you do if few thousands of the million items happen to be exceptional ? Resume Next could be one of the handy answers.
I've found that VB programmers often littered code with many
On Error Resume Next
statements out of (bad) habit. My suggestion would be to start with no suppressed exceptions, and see what actually breaks. There may not be as many issues as you think. Conversely, the more regression testing you can do, the better; there may be some edge cases that only work when errors are ignored.Ultimately, you need to decide on an error handling strategy, whether it is graceful unwinding inside many try/catch blocks, or letting errors percolate to a top-level handler (both strategies have their uses).
If you end up having to suppress some exceptions to meet a deadline, at the very least log those exceptions so that the next developer working on your code doesn't get burnt by an empty
try/catch
.Although sometimes this is acceptable, generally it indicates a code smell. If you're 100% sure you want to swallow the exception that has occurred you can do it the way you have, but generally if an exception is thrown you should do something.
Generally you can achieve the same outcome with well designed code. If you're currently experiencing a specific error, add it to your question, but if you're asking just out of curiosity, no there isn't an equivalent, and that is a good thing.
Although
On Error Resume Next
is certainly abused more than it's used legitimately, there are places where it would be helpful even in VB.NET.Consider a program which assigns values to a large number of Excel properties, such as defaults to all printer parameters -- there are a zillion printer parameters in Excel. Later versions of Excel might have properties which earlier versions don't support, and it isn't trivial to figure out which ones are supported in each version. The program should assign a value if the property exists but ignore the property if an older version of Excel is used.
The "right" way to do this with VB.NET would be to determine which printer properties are supported by each version of Excel, read the version in use, and only assign to properties that are implemented in that version. That would require a lot of research and some code, all for little benefit.
On Error Resume Next
would be a more practical solution.And, unfortunately, I'm faced with precisely this problem now. The workaround I'm going to try is to write a subroutine which just assigns one value to another, ignoring errors. I'll call this subrouting in place of each assignment statement. Not too terible, but not so great either.