In depth understanding of alternative implementation analysis of goto statements
- 2020-04-01 23:38:42
- OfStack
Once upon a time, goto let the cattle people to display their superb skills
Once upon a time, goto became the most evil
There was a time when goto was only an example in a textbook
There are so many reasons not to use goto, but sometimes we want to use goto's functionality.
Try /catch/finally can be used to achieve the same function as goto. Let's take a look at two examples:
And:
The above two paragraphs are equivalent to:
It's a bit violent in an unusual way, but it does help to implement functions like goto in the right way; Return and finally are not too violent, but they are difficult to control because the return statement is involved, which is executed after the finally block is executed, so if you don't want to exit the program, this method might as well be controlled with an exception.
In addition, break and continue are also powerful jump statements, especially the break label and continue label, which can break out of a loop or a multi-layer loop. However, it is important to note that break can only be used in loop and switch statements, and continue can only be used in loop statements. So they are very limited.
This small example shows that goto is not just a statement, it is a way of thinking and programming habits, people who are used to it, or want to use it, will write goto-like logic even without goto. The advantage is that it's easier to help find solutions. Its shortcomings are well known. But what we need to avoid is not just a goto statement, but this "jump" approach and programming habits.
Once upon a time, goto became the most evil
There was a time when goto was only an example in a textbook
There are so many reasons not to use goto, but sometimes we want to use goto's functionality.
Try /catch/finally can be used to achieve the same function as goto. Let's take a look at two examples:
try {
// operation one
if (failed) {
throw Exception;
}
// operation two
if (failed) {
throw Exception;
}
// operation three
if (failed) {
throw Exception;
}
} catch (Exception e) {
// do something when cases failed
}
And:
try {
// operation one
if (failed) {
return;
}
// operation two
if (failed) {
return;
}
// operation three
if (failed) {
return;
}
} finally {
// do something when failed
}
The above two paragraphs are equivalent to:
// operation one
if (failed) {
goto when_failed;
}
// operation one
if (failed) {
goto when_failed;
}
// operation one
if (failed) {
goto when_failed;
}
when_failed:
// do something when failed
It's a bit violent in an unusual way, but it does help to implement functions like goto in the right way; Return and finally are not too violent, but they are difficult to control because the return statement is involved, which is executed after the finally block is executed, so if you don't want to exit the program, this method might as well be controlled with an exception.
In addition, break and continue are also powerful jump statements, especially the break label and continue label, which can break out of a loop or a multi-layer loop. However, it is important to note that break can only be used in loop and switch statements, and continue can only be used in loop statements. So they are very limited.
This small example shows that goto is not just a statement, it is a way of thinking and programming habits, people who are used to it, or want to use it, will write goto-like logic even without goto. The advantage is that it's easier to help find solutions. Its shortcomings are well known. But what we need to avoid is not just a goto statement, but this "jump" approach and programming habits.