On error goto....

peterchen

After all, it could also have been ON ERROR RESUME NEXT

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist

Mike Dimmick

Phannon wrote:

At uni we had the true evil of the statement hammered into us on a C++ course, for every goto in our assignments you will lose 50% of the marks.

Stupid ivory-tower taboos. A goto statement can be helpful. But you should never use it where a structured control statement would be more appropriate. For some interesting reading see Gotos Considered Harmful and Other Programmers' Taboos[^].

DoEvents: Generating unexpected recursion since 1991

Paddy Boyd

:) very true. I shall be thankful for small mercies.

V 0

use goto, continue or break, you fail (break only allowed in switch statements.) use more then one exit in your function, you fail. and the prof was right... :)

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

CPallini

I fully agree with you. :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke

Brady Kelly

Mike Dimmick wrote:

Stupid ivory-tower taboos.

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

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