Do we have "on error resume next" in C#?

[Maxwell2006]

Hi,



I know that this is not a good practice, but I wonder do we have "on error
resume next" in C#?



Thanks,

Max

 

[ssamuel]

Max,

No. Are you nuts?

Seriously, no, there isn't, and all for the reasons that you'd expect.
There's really a whole lot you can do with try/catch blocks. Carefully
constructed code could do the same and more. Ask if you have a specific
need that someone may be able to help with.


Stephan

 

[Merlin]

I know that this is not a good practice, but I wonder do we have "on error

resume next" in C#?

Try..catch..finally is the best way... "on error resume next" would be
something horrible

 

[Jon Skeet [C# MVP]]

I know that this is not a good practice, but I wonder do we have "on error
resume next" in C#?

Fortunately not. Similar functionality can be obtained by using
try/catch within a loop.

 

[Tom Porterfield]

I know that this is not a good practice, but I wonder do we have "on error
resume next" in C#?

Fortunately, no we do not. You could emulate it by putting a try/catch
around each line of code. By doing so you quickly see why "on error resume
next" is such a bad idea in VB.

 

[Jon Skeet [C# MVP]]

Try..catch..finally is the best way... "on error resume next" would be
something horrible

In fact, try/finally is usually better than try/catch/finally - there
should generally be many more finally statements than catch statements,
as that indicates you have centralised error handling. It's not always
the case, but it's a good rule of thumb.

 

[sloan]

There was a "tension" when bringing vb6 to vb.net

this was one of the thing brought over, even though it was kind of a bad
thing.

That's why it was a vb.net thing only, because c# didn't have to deal with
the "upgrade" tension of vb6.

I'm just trying to share the ~why as opposed to the yes/no of it.

..net 2.0 tries to ease more of this "tension" by using the My. keyword to
wrap up some common functionality.

 

[Merlin]

In fact, try/finally is usually better than try/catch/finally - there
should generally be many more finally statements than catch statements,
as that indicates you have centralised error handling. It's not always
the case, but it's a good rule of thumb.

I fully agree. But it's hard to give generic laws, all depends on the
code style and a few variants can be accepted. try/finally or try/catch
or try/catch/finally are there and are all powerfull ways to build
code, but, of course, syntax elements are nothing if there's not a
solid plan in the mind of the developer...

 

[Tony Gravagno]

I fully agree. But it's hard to give generic laws, all depends on the
code style and a few variants can be accepted. try/finally or try/catch
or try/catch/finally are there and are all powerfull ways to build
code, but, of course, syntax elements are nothing if there's not a
solid plan in the mind of the developer...

Don't forget that we can have multiple catch blocks on a single try to
handle specific exceptions. That fact could inflate the number of
catches way past finally blocks. Does it seem like most people just
"catch (Exception ex)" as their first option?

On Error Resume Next can easily be implemented as:
try { foo; } finally {}
Sometimes you don't care if there is an exception thrown, like in a
final wrapup routine, you just want to do what you can and get out of
there as fast as possible.

 

[Jon Skeet [C# MVP]]

On Error Resume Next can easily be implemented as:
try { foo; } finally {}
Sometimes you don't care if there is an exception thrown, like in a
final wrapup routine, you just want to do what you can and get out of
there as fast as possible.

I'm not a VB programmer, but that doesn't sound like it's the same
thing at all. If foo throws an exception, then the above code will
effectively rethrow the exception - it *won't* resume execution on the
next line, which I *thought* was the behaviour of On Error Resume Next.

As I understand it, On Error Resume Next is closer to:

try { foo; } catch {}

 

[Tony Gravagno]

I'm not a VB programmer, but that doesn't sound like it's the same
thing at all. If foo throws an exception, then the above code will
effectively rethrow the exception - it *won't* resume execution on the
next line, which I *thought* was the behaviour of On Error Resume Next.

As I understand it, On Error Resume Next is closer to:

try { foo; } catch {}

Yup yup, I was looking at the comments on Finally and should have
typed Catch. Duh, sorry.

 

[Michael D. Ober]

It's more than that:

On Error Resume Next
Statement1
Statement2
Statement3

Translates to
try { Statement1; } catch {}
try { Statement2; } catch {}
try { Statement3; } catch {}

There are very few situations where On Error Resume Next is appropriate. I
use it primarily when I'm configuring the run time environment and some of
the configuration has already been done. Rather than test each
configuration item, I simply don't care if the item is already configured
and reconfiguring it throws an error. That said, you definitely have to
keep the On Error Resume Next modules in VB short and to the point.

C# doesn't have a direct equivalent to "On Error Resume Next".

Mike Ober.