Quite often Im using local procedures where I would like to return from the main procedure, but I cant put a
Return mainproc expression
inside a local procedure.
Sort of like the same thing you can do with cycle [label] but with return.
Good idea? Bad idea?
TIA
I’m a pretty solid no on that one.
Solid no for what?
Good idea?
Bad idea?
Not a good idea, IMO.
Whats the pitfalls?
Harder to follow in the debugger?
Maybe you haven’t suffered through numerous GOTOs before, but the embracing of a GOTO code construct idea brings back the flashbacks 
It seems to be an unnecessary complication, where a simple re-design might be more elegant.
Using ABC? How about potential problems with not running code in the Kill method or for a general case, any needed procedure clean-up code.
Gotos are no different to a procedure call though.
Well if thats the attitude, why program?
I’ve used up my 2 cents on this issue.
It would save me having to write code to test the returnvalue in the calling procedure.
More code = more bugs.
As far as I understand, Clarion does not allow GOTO outside its scope today. I think it is fine to do so. Knowing a Label outside the current scope is too dangerous. The same thing that can be done with a return can be done with a jump using a GOTO.
Thats one way to look at it, but if cycle can have a label to jump back to an outer loop, should scope even be a factor?
Id be happy if I could a return from a local procedure that took me out of the parent procedure.
Im not asking for a return that could exit the program. But if this is such a dangerous facility to have, can we even be trusted to write code then?
Should we now just use ai to do our coding?
I’m thinking it might be an unnecessary complication.
you can simply say something like
if myCalledProc() = -1 then return.
so if you want to escape two levels then within myCalledProc just
return -1
You wouldnt have to use it, but it would make my code simpler and easier to read because of the error checking Im now doing. A DABS defensive programming technique which can negate the need for a debugger even. Ive already found omitted() doesnt work if placed in a local procedure which only became detected with greater defensive programming techniques. The compiler never helped me in that situ and I wonder what else Ill find in the future.
just following on from this idea, you can choose to return multiple levels where you specify how many to return:
x long
code
x = myCalledProc()
if x < 0 then return x+1.
and have the same protocol up and down the chain, so if you want to return 3 levels, that is two extra levels over a normal single level return, so you say:
return -2
I was thinking if you allow the returning back without a specific protocol like that mentioned here, you might put some debug code in after a procedure call - but it never gets performed as it returns up multiple levels and you are left scratching your head. With the above idea, (whether you like the idea or not), it is at least apparent what is happening and you are not wondering why the code never seems to return from your procedure call (until an hour later you realize you were leap-frogged on a multi-level return).
So take the strposprocess proc Ive been working on recently. I return clarion errors as postive integers and my unit test fails and my code errors are returned as negative error codes.
A label would be a concious decision to return to the procedure name specified.
So I dont think a return -x would be useful as it prevents programmers from using negative error codes unless you are saying return -2 -7 ie two negative numbers where -2 is return two procedures and -7 is the negative errorcode?
you can only return one value from a procedure/function so the usual ways to get around this is to either pass parameters by reference (so you can return an altered value) or to have two numbers (of a given range) stored in one.
so say you wanted to have return values with a maximum range of ±1000
so for negatives that would be -1 to -999
so to your example of -2 -7 you could return -2007
this can be split up in the calling proc
levels = int(retVal / 1000)
retval = retVal % 1000
so it can be done but possibly (probably?) more trouble than it is worth.
having said that you need to be careful of using modulus with negative numbers as there are two different conventions. There is a pragma compatible_modulus related to this:
#pragma define(compatible_modulus=> on | off )
Controls the sign of the result of modulus division.
If the pragma is set to zero (OFF), the modulus result
uses the sign of the divisor. If the pragma is set to
one (ON), the modulus result uses the sign of the
dividend.The default is off.
Example:
If compatible_modulus = 0, then
42 % -5 = -2 (-5 is the divisor(-) )
If compatible_modulus = 1, then
42 % -5 = 2 (42 is dividend (+))
I was questioning you. I know you can only return a single value, but if you happened to devise a method where you could combine two values into one and then decipher it on the otherside, yes it would be possible to return two values.
I know parameters passed by address can be used to pass a value back unlike the one way passed by value method. 
Ive actually ditched the return of positive errors as clarion errors and negatives as my code and just gone with returning an error code which identifies the error with the info I need. Although ghidra and other tools can be used to look at the code, no point in giving too much away too easily. 