RAD Basic

TNCaver

I finally read the Register article on the so-called "Visual Basic 7" and of course it referenced the infamous On Error Resume Next command (also found in Classic ASP). While that can lead to bad programming practices, the devil's advocate in me asks how is it any different/worse than the C# code below, or are they both frowned upon?

try
{
SomeCommandWithRiskOfFailure();
}
catch (Exception ex)
{
// do nothing
}

If you think 'goto' is evil, try writing an Assembly program without JMP.

OriginalGriff

Much worse: it's the equivalent of this:

	try { DoSomething(); }
	catch {}
	try { DoSomething1(); }
	catch {}
	try { DoSomething2(); }
	catch {}
	try { DoSomething3(); }
	catch {}
	try { DoSomething4(); }
	catch {}

It discards errors with no hope of telling if they ever occured, no debug to find out what failed or why, and worse, it's hidden in a single line of code that could be pages away from the faults. So if you just look at the "relevant code fragment" you have no idea that every problem is being swallowed and ignored. On Error Resume Next is a good reason why VB should just be banned ... :-D

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

TNCaver

True, but there are infrequent cases where the error condition truly is inconsequential.

If you think 'goto' is evil, try writing an Assembly program without JMP.

OriginalGriff

Yes, and for those it's a good idea to put an "empty" try-catch around the code which will fail (or better, log it in a catch block). Just being able to go "my code is right: look no errors" by putting On Error Resume Next right at the top of your code is horrific!

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!

Dave Kreskowiak

On Error Resume Next is far worse than the empty catch block. In VB, the code will keep trying to execute line after line of code, even if they all fail, until the On Error is rescinded by another On Error line. This can lead to data loss if not carefully managed. You also lose all of the error information on the original failure and the error handling model doesn't lend itself to the easy logging of errors. An exception in a try block will simply stop executing that code and jump straight to the empty catch block, then a finally block (if supplied.) Even if the catch block doesn't do anything to recover from an exception, you can at least still easily add code to log the error and other metadata in one place.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

Slacker007

OriginalGriff wrote:

It discards errors with no hope of telling if they ever occured,

What I do in this scenario is create a ResponseDto object and add a List to it so that all my methods return that Dto object with any exceptions. That way you can handle the exception at the top of the call stack. My preference is to only use Try/Catch in the UI/front end if possible and not in the middle tier or supporting code libraries.

obermd

On Error Resume Next has a place. I have found it makes for cleaner code in situations where you really don't care if each statement completes error free or not, such as in clean up code before an application terminates. It's certainly cleaner than a slew of repeating try { Statement } catch {} blocks.

obermd

On Error Resume Next is cleaner in these situations.

obermd

Which means that semantically and execution sequences the two options are different.

Roland M Smith

If you make any piece of software idiot proof, only an idiot will be willing/able to use it.

Mycroft Holmes

What! - The goal of any decent developer is to make their software idiot proof, that does not mean nagging them to confirm every step they take it is to catch and deal with all the edge cases and errors that occur.

Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP

jeron1

:thumbsup:

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Gary R Wheeler

Between your post and your sig, it sounds like you have a large chip on your shoulder about language constructs that allow goto and related, unstructured behaviors. I'm not trying to start an argument, but I'm curious: why is that?

Software Zen: delete this;

TNCaver

LOL There's no chip on my shoulder, you're reading way too much into it. I just notice opinions and positions on matters that seem contradictory to me and often point them out.

If you think 'goto' is evil, try writing an Assembly program without JMP.

TNCaver

I agree, though I seriously doubt that's the reason any programmer worth his salt would use it.

If you think 'goto' is evil, try writing an Assembly program without JMP.

kmoorevs

TNCaver wrote:

is it any different/worse than the C# code below

I wouldn't use the word 'worse' as they are both perfectly legitimate ways of dealing with either expected or unexpected errors. Judging by your sig, you already know this, but I can appreciate livening up the conversation here with a flame war. :laugh:

"Go forth into the source" - Neal Morse "Hope is contagious"

TNCaver

Honest, I wasn't trying to start a war! :sigh:

If you think 'goto' is evil, try writing an Assembly program without JMP.

trønderen

I have several times written code that was greatly simplified by explicitly ignoring errors after 'optional' operations. A trivial example: If a personal user profile is available, use it to initialize the environment. If it is not, it really doesn't matter why not (in some environments, it might matter, but not in my cases). Otherwise, if an installation default profile is available, use that. If not, ignore the reason why it is not available, and use a hardcoded default profile. The application comes up running; that's the important thing for the user. Failing startup with a complex explanation that a user won't understand anyway is far less satisfactory. For a first-time user, there will be no user profile; it is created from the first or second fallback. Defining an installation default profile is optional (and for a PC with a single user, it doesn't make sense), and setting it up requires far more understanding than from a first time user. The #1 reason why the two first steps may fail is "It hasn't been created yet". I have not yet experience any other reason that a first time user would be able to fix even if the error message was displayed. When the user exits the application, the personal profile is saved. Now, thorough checks are made. If there are conditions making that impossible, it will probably reveal the reason why the startup reading of the profile (which should have been there - the user is a returning one) failed. This happens very rarely, and doesn't bother the first time user. I have never experienced any case where reading a profile would fail but writing would succeed for any other reason than that it doesn't exist and will be created. So any other problem will be detected - without stopping the user from doing his work (although under a default profile). You might argue: But for your own purposes, you should log the problem, even if you don't display the error to the user. That log would, in 99,9% of all cases, tell me: Reading user profile failed because this is a first-time user. Reading installation default profile failed because no installation default profile has been created. Well, I know that! I don't need a log file to tell me! For other failure reasons, the error report from saving the user profile will be good enough. This reading of a user profile is one of three or four cases of "See if you can do the operation. If you cannot, it isn't a big deal - maybe even expected - so don't bother the user with it". Another case that comes to m