|
|
1. Create a workflow manager using generics, interfaces, class abstraction, enums for state and continuation.
2. Break up your code into small workflow steps.
3. On each step, check for termination.
4. Or to get really fancy, return a code that says what step in the workflow to skip to.
5. If you really want to be cool, allow for async workflow steps!
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
When can I read the article ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
 
Nuke the location in which the GOTO was used, sow the glass crater with salt, and plow it in. Then scatter biological and chemical agents all around the area, making it inaccessible for 10,000 years!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It4 seems to me that in a language with no local functions or lacking in structured error handling, gotos have a useful place. A limited place, but a place all the same.
|
|
|
|
|
I use goto all the time.
Every loop and conditional expression you use calls it to their hearts' content; there's no avoiding it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
<snicker> I started coding in SuperBase, GOTO and GOSUB were standard and recommended constructs. Transitioning to VB in the 90's was no benefit. It was only when I started using c# that I abandoned them completely.
Some of us have shameful pasts.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
These days the "goto" is back, I find this very unfortunate.
Every time someone writes a RETURN or a BREAK statement, he/she is actually writing a GOTO
And the worse thing about it is that this is encouraged these days...
|
|
|
|
|
he's back, and he's angry! 
however I do believe that while do jump the code pointer, they are their own assembly instruction!
|
|
|
|
|
The GOTO statement used to be pure evil. In BASIC it used to go to a line number. Not very easy to understand what it is intended to be doing at the best of times. Add in the fact that you could renumber every line in the program with the RENUMBER command and the GOTO statements would not update to reflect the line number changes and you have GOTO hell. (Not to mention that a lot of versions of BASIC at the time had missing features, for example procedures, functions, while loops, repeat loops.)
These days with the GOTO statement going to a label it has had it's teeth filed and, while not a common feature is nothing to be afraid of.
|
|
|
|
|
What language?
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
|
Code sample would be nice. Because honestly, with the amount of control structures and object orientation support it provides I don't see a reason to use it. In fact. I work with C# since I was 24 years old (I am 36 now). Never had to use goto since (except from a few side projects in C).
I used moro goto on imperative/structured/procedural languages like C, C++ and BASIC. So on purely objected oriented programming, whenever I thought of goto, it flashed a yellow light to me indicating I probably got some design patterns wrong. After some time I never got that yellow light again.
I am not saying your use is not justified, I just can't wrap my head around a reason to use it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I didn't use goto in the end.. had to write a public static function and used it instead....
|
|
|
|
|
I much prefer "goto case something;" to "", i.e. a silent fallthrough.
|
|
|
|
|
See my signature.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Use of GOTO is not always bad, nor a sign of poor design. Have a look at the Linux kernel source code sometime. You will see it littered with GOTOs everywhere. GOTO is an elemental part of their error-handling paradigm, they use it in a defined and regular way. The Linux kernel is not the only major and highly regarded software project to use this method, either, it just may be the most prominent.
But that said, a colleague of mine tried to employ the same paradigm to some of our own in-house code, and upper management pitched a hellacious fit when they got wind of somebody trying use GOTOs. A group of developers (very good ones) mounted a defense of it, but it was no use. Everybody flatly over-ruled, everybody shamed for having the thought.
|
|
|
|
|
static STATUS Android_PrepareAudioBuffers(void) {
STATUS errCode;
SLresult result;
_slBufferQueueItf = NULL;
result = (*_slRecorderInstance)->GetInterface(_slRecorderInstance, SL_IID_ANDROIDSIMPLEBUFFERQUEUE,
&_slBufferQueueItf);
if( result != SL_RESULT_SUCCESS ) {
LOGE("%s - Error calling _slRecorderInstance->GetInterface(SL_IID_ANDROIDSIMPLEBUFFERQUEUE)", __func__);
errCode = S_ERR_OPENSLES_GET_INTERFACE;
goto fail_point;
}
result = (*_slBufferQueueItf)->RegisterCallback(_slBufferQueueItf, Android_RecordCallback, NULL);
if( result != SL_RESULT_SUCCESS ) {
LOGE("%s - Error calling _slBufferQueueItf->RegisterCallback()", __func__);
errCode = S_ERR_OPENSLES_REGISTER_CALLBACK;
goto fail_point;
}
(*_slRecorderItf)->SetCallbackEventsMask(_slRecorderItf, SL_RECORDEVENT_BUFFER_FULL);
_activeBuffIdx = 0;
int i;
for( i = 0; i < RECORD_BUFFER_COUNT; i++ ) {
result = (*_slBufferQueueItf)->Enqueue(_slBufferQueueItf, _buffers[i], _buffSz);
if( result != SL_RESULT_SUCCESS ) {
LOGE("%s - Error calling_slBufferQueueItf->Enqueue()", __func__);
errCode = S_ERR_OPENSLES_ENQUEUE_BUFF;
goto fail_point;
}
}
return S_OK;
fail_point:
if( _slBufferQueueItf ) {
(*_slBufferQueueItf)->RegisterCallback(_slBufferQueueItf, NULL, NULL);
(*_slBufferQueueItf)->Clear(_slBufferQueueItf);
_slBufferQueueItf = NULL;
}
return errCode;
}
modified 21-Jun-19 11:29am.
|
|
|
|
|
Which language?
Probably a member of the "C" family. (C, C++, C#)
Java killed goto with the "labeled break" which allows you to only "goto" the statement after a close curly brace.
|
|
|
|
|
C#
used a static public function instead..
because it turned out...
|
|
|
|
|
I grew up on assembly code in the late 70's so I have no issues using goto's in my coding (C/C++ these days) when approriate. The idea that goto's are inherently bad is just bogus. There is a relatively small class of functions that are shorter and easier to understand when coded with a goto as opposed to the convoluted looping required to do the same thing. And being an old fart, shorter and easier to understand is a good thing! Especially when I have to add new features to code I wrote years ago.
|
|
|
|
|
As others have said, it's largely what Try Catch does. It has been pointed out though that using break and return in a method is really the same thing in a way. I've used on goto in my code, but based on that last sentence I plan to use them regularly though in the future, just always within a method. Instead of a catch -> return -> handle error, use a catch -> goto error handling at end of method -> end of method returns.
|
|
|
|
|
Does anyone remember when the use of gotos was first discussed? Does anyone remember the reason Dijkstra gave for their elimination?
To me, I'm sorry, this thread seems somewhat juvenile
Gus Gustafson
|
|
|
|
|
It's not bad, it's dangerous. But there's use cases where it's better than, let's say, 12 nested ifs. Did that myself, some COM-code which calls COM-methods in order I've placed gotos between method calls to directly jump to cleanup/deinitialization/error handling instead of a pile of if NoError=SomeMethod {if NoError=NextMethod). Way cleaner, but requires knowing what I'm doing. One wrong goto and I'm screwed.
|
|
|
|
|
there's nothing inherently wrong with goto, it's just another tool that works just like OP jump codes on a processor, jumping the running process to another memory location.
It's quite handy too when the code structure gets nested too deep or you can't use recursion; it has it's place, and can keep the code more readable when done right.
Unfortunately before structured programming came around that's all you had to move around, this was quite common in early version of BASICA or GW, where using subroutines wasn't as common. all this turned in to spaghetti code, earning procedural languages like Basic a bad rep (that stuck). the developers that grew up on these early languages unfortunately carried this forward using goto's everywhere, making it a nightmare to debug when something went wrong.
My personal rules for goto's:
*keep the function as short as possible so you can see the GOTO and the LABEL on the screen at the same time.
*never use more than one redirection, ie multiple goto's to one label is fine if absolutely necessary, but never ever use multiple goto's and multiple labels, that just too much jumping around, and gets hard to follow.
*does the code look cleaner and easier to follow with a goto or using check values with more if's?
*can the process be restructured to avoid the deep nesting that caused a goto to be used in the first place.
*keep the code as simple as possible.
That being said, I've used goto maybe 5-10 times in my 20+ years developing, and I don't regret it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
