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?
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.
No, it's not the same.
When using On Error Resume Next, VB would skip to the next line if an error occurs. With try/catch, execution jumps to the catch block if an error (exception) occurs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With