Yes, I looked at various ways of implementing GOTO in java, but here is the real world: I need one of the latest fortran LAPACK routine converted to java, see http://www.netlib.org/lapack/timing/eig/eigsrc/dlasq3.f e.g.:
10 CONTINUE
IF( N0.LT.I0 )
$ RETURN
IF( N0.EQ.I0 )
$ GO TO 20
NN = 4*N0 + PP
IF( N0.EQ.( I0+1 ) )
$ GO TO 40
OPS = OPS + DBLE( 3 )
IF( Z( NN-5 ).GT.TOL2*( SIGMA+Z( NN-3 ) ) .AND.
$ Z( NN-2*PP-4 ).GT.TOL2*Z( NN-7 ) )
$ GO TO 30
20 CONTINUE
fortran code ...
GO TO 10
30 CONTINUE
OPS = OPS + DBLE( 2 )
IF( Z( NN-9 ).GT.TOL2*SIGMA .AND.
$ Z( NN-2*PP-8 ).GT.TOL2*Z( NN-11 ) )
$ GO TO 50
40 CONTINUE
fortran code ...
GO TO 10
50 CONTINUE
What would be a "standard" way to deal with all possible GOTOs?
The best way to handle this is to compose each logical block as a section and make a state diagram for the entire function.
Don't forget that falling through past the start of a state is considered a transition and should be treated as such. When you have these broken out into their state transitions, you can start to see where they can be reduced into a handful of functions, applying recursion or iteration where necessary.
Now, I fully admit that I don't understand the function or what it's doing or supposed to do, but this was a first attempt at making the state diagram, to give you an idea of what I mean. Notice the loop on 80
, probably going to need a loop. Notice that 10 and 100 are your only return states. Notice how once you go from 30 to 50 there is no going back. That indicates to me that 50+ might be it's own isolated function, while 10-40 is it's own function with a loop that when it hits 30 says return functionRepresenting50Pluss(...)
Just a note, the filled in squares on some state transitions indicate this transition is guaranteed to be chosen if no other transition is made away from the state. Notice it doesn't exist on 80 because I couldn't really decide if 80 or 90 was it's guaranteed destination. It could be it's possible for something to loop around 80 forever? Without understanding the function more I can't say.
GOTOs are considered an anti-pattern. You should never try to convert it straight to Java without considering redesigning the code.
For example, when you see a label for GOTO, that is likely a sign that this code would be reused. Should it belong in a method to be called again in the future instead? Approach the new design using OO rather than using the same procedural train of though as that in FORTRAN.
Java does work in the real world without GOTOs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With