What is the best alternative “On Error Resume Next

2019-04-04 09:09发布

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?

11条回答
Lonely孤独者°
2楼-- · 2019-04-04 09:29

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 :)

查看更多
老娘就宠你
3楼-- · 2019-04-04 09:35

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.

On Error Resume Next
<something that may throw an error>
If Err.Number <> 0 Then
   <do something about this specific line of code>
   Err.Clear()
End If

Or, you may see this:

Sub DoSomething

   On Error Goto Handler1
   <do something that causes an error>

   On Error Goto Handler2
   <do something that may cause an error>

   Exit Sub

   Handler1:
   <log error or something>
   Resume Next

   Handler2:
   <log error or something>
   Resume Next

End Sub  

But in old VB6 code you will likely also see this...

Sub PerformThis
On Error Resume Next

End Sub

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..

try { _objectinfo.Add(_object.attribute1); } catch (Exception _e) { }

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...

try { PerformAction(); } catch (Exception _e) { }

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...

查看更多
Ridiculous、
4楼-- · 2019-04-04 09:36

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.

查看更多
迷人小祖宗
5楼-- · 2019-04-04 09:41

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.

查看更多
爷的心禁止访问
6楼-- · 2019-04-04 09:42

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.

查看更多
▲ chillily
7楼-- · 2019-04-04 09:42

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.

查看更多
登录 后发表回答