# Feature Request: return \[label\] \[expression\] **URL:** \ **Category:** Feature Requests\ **Tags:** language\ **Created:** [October 22, 2024, 12:16pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593 "2024-10-22T12:16:34Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 12:16pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/1 "2024-10-22T12:16:34Z")
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 ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [October 22, 2024, 2:37pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/2 "2024-10-22T14:37:02Z")
I’m a pretty solid no on that one. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 3:10pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/3 "2024-10-22T15:10:53Z")
Solid no for what? Good idea? Bad idea? ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [October 22, 2024, 3:42pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/4 "2024-10-22T15:42:49Z")
Not a good idea, IMO. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 4:01pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/5 "2024-10-22T16:01:02Z")
Whats the pitfalls? Harder to follow in the debugger? ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [October 22, 2024, 4:51pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/6 "2024-10-22T16:51:03Z")
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. ---
**Author:** ![totalhip](https://clarionhub.com/user_avatar/clarionhub.com/totalhip/32/1477_2.png) [@totalhip](https://clarionhub.com/u/totalhip)\ **Post date:** [October 22, 2024, 5:16pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/7 "2024-10-22T17:16:00Z")
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. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 5:45pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/8 "2024-10-22T17:45:10Z")
Gotos are no different to a procedure call though. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 5:45pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/9 "2024-10-22T17:45:36Z")
Well if thats the attitude, why program? ---
**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\ **Post date:** [October 22, 2024, 6:01pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/10 "2024-10-22T18:01:47Z")
I’ve used up my 2 cents on this issue. 🙂 ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 6:13pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/11 "2024-10-22T18:13:37Z")
It would save me having to write code to test the returnvalue in the calling procedure. More code = more bugs. ---
**Author:** ![Gustavo\_Saracca](https://clarionhub.com/user_avatar/clarionhub.com/gustavo_saracca/32/5355_2.png) [@Gustavo\_Saracca](https://clarionhub.com/u/Gustavo_Saracca)\ **Post date:** [October 22, 2024, 9:47pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/12 "2024-10-22T21:47:41Z")
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. ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 11:28pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/13 "2024-10-22T23:28:56Z")
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? ---
**Author:** ![vitesse](https://clarionhub.com/user_avatar/clarionhub.com/vitesse/32/837_2.png) [@vitesse](https://clarionhub.com/u/vitesse)\ **Post date:** [October 22, 2024, 11:30pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/14 "2024-10-22T23:30:15Z")
I’m thinking it might be an unnecessary complication. you can simply say something like ```auto if myCalledProc() = -1 then return. ``` so if you want to escape two levels then within myCalledProc just `return -1` ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 22, 2024, 11:41pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/15 "2024-10-22T23:41:14Z")
> [@vitesse](#): > > I’m thinking it might be an unnecessary complication 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. ---
**Author:** ![vitesse](https://clarionhub.com/user_avatar/clarionhub.com/vitesse/32/837_2.png) [@vitesse](https://clarionhub.com/u/vitesse)\ **Post date:** [October 23, 2024, 12:20am UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/16 "2024-10-23T00:20:50Z")
just following on from this idea, you can choose to return multiple levels where you specify how many to return: ```clarion 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: ```auto return -2 ``` > [@vitesse](#): > > I’m thinking it might be an unnecessary complication. 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). ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 23, 2024, 12:55am UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/17 "2024-10-23T00:55:54Z")
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? ---
**Author:** ![vitesse](https://clarionhub.com/user_avatar/clarionhub.com/vitesse/32/837_2.png) [@vitesse](https://clarionhub.com/u/vitesse)\ **Post date:** [October 27, 2024, 10:39pm UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/18 "2024-10-27T22:39:53Z")
> [@RchdR](#): > > 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: ```plaintext #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 (+)) ``` ---
**Author:** ![RchdR](https://clarionhub.com/letter_avatar_proxy/v4/letter/r/d78d45/32.png) [@RchdR](https://clarionhub.com/u/RchdR)\ **Post date:** [October 28, 2024, 2:55am UTC](https://clarionhub.com/t/feature-request-return-label-expression/7593/19 "2024-10-28T02:55:02Z")
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. 😉