On error goto....

[Brady Kelly]

Paddy Boyd wrote:

Stupid ivory-tower taboos.

I almost worked on a POS, also littered with those, but with the added qualifications, such as If Err.Number = nnn Then Resume Next Trying to find an error causing line was hell, because with Break on All Errors turned on, nearly every line caused an error, which was handled by code such as the above. Things like invalid array indexes, empty strings etc. that could all have been ignored with a proper code check, such as If i > UpperBound Then DoNothing, but no, it was just Write strData(i) and let the f****ing error handler see if the error was important.

[David Stone]

Agreed! On Error Resume Next, to me, always seems like saying "Eh. Who cares about what we're doing. The user should notice that half their data failed to get through our routine and fix it themselves..."

[Mike Dimmick]

It's the only way of handling exceptions in VB6. VB6 also wouldn't give you a call stack so you basically had to do it yourself by putting On Error Goto in every function. Now, if it was ported to VB.NET and not translated to Try/Catch, then you have my sympathy. If it was written new in VB.NET, not a translation from VB6, then the programmer should be shotretrained.

DoEvents: Generating unexpected recursion since 1991

[Paddy Boyd]

I know. And i believe, written from scratch...

[NormDroid]

You'll find goto used in Microsoft code especially in cleanup functions.

There is no Ctrl button on Chuck Norris's computer. Chuck Norris is always in control

[Brady Kelly]

I often use continue. It greatly improves readability.

[Brady Kelly]

Mike Dimmick wrote:

Now, if it was ported to VB.NET and not translated to Try/Catch, then you have my sympathy.

Or if it was, but with every (now) method being neatly wrapped up in a 'try' 'catch (Exception ex)' 'throw new Exception("Error!", ex);'

[BadKarma]

Brady Kelly wrote:

Yes, I agree, but On Error Resume Next should be punished by stoning to death with golf balls.

True, but that should also apply to the try/catch/do-nothings.

codito ergo sum

[Brady Kelly]

Yes, even the try/catch/do-nothing-but-throw-again-and-break-the-call-stack.

[JudyL_MD]

Multiple exits can greatly improve readability when you have extensive error checking at the start of the routine. Judy

[Andy Brummer]

I've seen way way too many of those in the short time that I've been working in C#. It's too late now, but it should have been the first thing taught to every VB developer making the transition. Even before they learned the syntax.

This blanket smells like ham

[Andy Brummer]

I use continue all the time, and if you have a function that doesn't support multiple return statements easily then your function is probably too complicated. Though, back in the C days it was hard to keep functions simple enough. My arbitrary flow control dogma would be if you have more then 2 nested if, while, switch or for statements you fail.

This blanket smells like ham

[V 0]

Andy Brummer wrote:

if you have a function that doesn't support multiple return statements easily then your function is probably too complicated

On the contrary, bugfixing with your function only having one return is more easy than when it has, let's say, 5 return statements. There's nothing more ugly then having something like this

if(something == true){
return;
}

tastes differ I guess :-)

V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive

[Dan Neely]

With extensive (more than 2 or 3 checks) I generally refactor all the error checking into bool ValidateFunctionName(...).

Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull

[JudyL_MD]

True, but that Validate function is still easiest to read if it has multiple return false statements for each error check that fails and one final return true at the end if it passes all the tests. Regardless of where the error checking is, I always find it more readable to do it this way rather than massively nesting the multiple error checking to force the routine into only having a single exit point - the OP's original point. Judy