Open jacobwilliams opened 2 months ago
I have also wanted this for the same reason.
The best alternative I can think of is putting the body in a block and then branching out:
subroutine main()
try: block
! some stuff
if (error) exit try
! some other stuff
return !<--- have to remember to put this here
end block try
call raise_error()
contains
! ...
end subroutine
The other way would be goto
but I hope we all agree this isn't pretty:
subroutine main()
! some stuff
if (error) goto 999
! some other stuff
return !<--- have to remember to put this here
999 call raise_error()
contains
! ...
end subroutine
The numeric labels feel anachronistic (even C has named labels!) plus they completely mess up formatting in free-form.
I've been meaning to submit a paper to expand the rules for goto to allow named labels:
subroutine main()
! do stuff
if (error) goto error_handling
! do other stuff
return !<--- still have to remember to put this here
error_handling: block
call raise_error()
end block error_handling
contains
! ...
end subroutine
This would also be useful for I/O procedures which allow jumping to numeric label upon error, so it can be pursued independently of what you are proposing here.
subroutine outer
call other(inner)
contains
subroutine inner
return outer
end
end
subroutine other(e)
call e
end
@klausler I can't even wrap my head around this example, let me try:
subroutine outer
call other(inner)
contains
subroutine inner
return outer
end
end
subroutine other(e)
call e
end
Let's inline other
:
subroutine outer
call inner
contains
subroutine inner
return outer
end
end
Ok, so this should just return from outer
it seems.
Is your point how to do this when other
can be defined in another module, or linked later?
Couldn't one just add a rule that a procedure returning from outer
cannot be passed as a procedure argument or associated to a procedure pointer, but only used via a direct call in the applicable scope?
@ivan-pi it's a useful pattern that I use quite often to pass the inner procedure as a callback into some solver. It allows me to "pass the context" that way.
That is useful indeed. I meant only for the case where the inner procedure would return to somewhere else than the place where it was called itself.
I have no idea what these outer/inner examples are trying to show here. I think it's too late in the day on Friday or something.
@ivan-pi Yes the block thing is as good as we have now I think. But it would be annoying to have to put a block and indent every single subroutine we write.
In reality, what we really need is some kind of actual exception handling feature in Fortran. But I fear we will never get that.
In reality, what we really need is some kind of actual exception handling feature in Fortran. But I fear we will never get that.
I know that they are disapproved, and work only for subroutines, but alternate returns are somewhat adjacent to a decent procedure-scoped exception mechanism that exists today. Perhaps they could be rehabilitated and lightly extended (to work with functions, and to permit forwarding of inbound alternate return arguments to outgoing calls).
Hi.
(This post is a bit self-promoting, but...)
A while ago I proposed an exception handing mechanism, and today I posted an updated version ---which I think covers the issue here.
Here's a little thing that I have frequently wanted: some syntax to allow a
contained
procedure (say in a subroutine) to have areturn
statement that applies to the calling procedure. This is to replace something like this:with: