have a look at this code snippet
METHOD PUBLIC CHAR EXTENT GetInboundFiles(): DEF VAR lv_Files AS CHAR EXTENT NO-UNDO. IF EXTENT(lv_files) EQ ? THEN RETURN ERROR "No files found". RETURN lv_Files. END METHOD.
METHOD PUBLIC CHAR EXTENT GetInboundFiles():
DEF VAR lv_Files AS CHAR EXTENT NO-UNDO.
IF EXTENT(lv_files) EQ ? THEN RETURN ERROR "No files found".
Why won't this compile ? Is it a bug in the ABL ? How can I return an error if I have a indeterminate array as the return value ? This is the error message:
RETURN statement expression must have the same extent as method or function return definition unless one of them is indeterminate. (14913)It is better to have an array as an output parameter than a return value. But if it is necessary to have it as a return value, then either it has to be indeterminate or match the extent in the method or function definition, unless that is indeterminate.
RETURN statement expression must have the same extent as method or function return definition unless one of them is indeterminate. (14913)
It is better to have an array as an output parameter than a return value. But if it is necessary to have it as a return value, then either it has to be indeterminate or match the extent in the method or function definition, unless that is indeterminate.
1) Why is it "better" to have an array as an output parameter ?
2) I am not returning the array, I'm returing an ERROR
UNDO, THROW NEW Progress.Lang.AppError ("File not found") .
Should have the same effect. RETURN ERROR is very retro
I agree its confusing and could be considered a bug but not anything that could be changed at this point in the life of ABL RETURN ERROR. As Mike said this is something we fixed with structured error handling and it is best to use that. since there is full mapping between classic and structured error handling Mike's suggestion is the best way to go.
* jmls dons his 70's shades ...
The irony of this was that I am in the middle of implementing structured error handling . lol.
You must be doing a lot of interesting work lately, Julian, since you seem to keep coming up with interesting questions.
Shelley, is the issue here the fact that the return value of the method has been defined as an indeterminate extent, but the extent is never determined? Would this work if the extent of the return value were determined?
I think Mike is right, that the structured error handling is to be preferred regardless and it may get away from this issue as well, but I'm wondering if it is that combination which is the issue.
There is a part of me which would rather return an object with an indefinite number of contents instead of an indeterminate extent.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
Will be doing that.
"interesting" is a word that could be used. There are a lot of other, more anglo-saxon terms I am using at the moment
Don't forget to add ON ERROR UNDO, THROW to all FOR and REPEAT LOOPs
I've met a number of developers, that were thinking that ROUTINE-LEVEL ON ERROR, UNDO THROW is enough (including me when I started using structured EH)
In answer to your question, even if the array is determined ( extent(foo) = 10 ) then you still can't RETURN ERROR.
however, RETURN ERROR is so retro these days ...
got bit in the ass by that on Friday. The realisation of this made a
whole load of things suddenly make sense !
We need a
LOOP-LEVEL ON ERROR, UNDO THROW
or a startup option to implement this. Really am not looking forward
going through all the code to add this in
On 13 February 2011 20:34, Mike Fechner
Something like that also came into my mind. Where's the ERS, when you need one?
Tedious, perhaps ... another argument in favor of code generation!
But, I wonder if it wouldn't be a bit dangerous to make it sweeping without considering case by case. ROUTINE-LEVEL I can see since one of the first things one ought to do in implementing SEH is to put in a top level handler for everything that doesn't get handled below. LOOP-LEVEL I'm not so sure about.
But, whatever, I'm not sure that the difference between an available ERS and a not available ERS will be noticeable in terms of what gets in the product (who me, cynical?)
No - it has to do that RETURN ERROR only works with a string but when it is used in a function with a return type that is not CHAR then you can't RETURN ERROR string anymore - the compiler complains. So RETURN ERROR cannot return a CHAR EXTENT but you also can't return a CHAR now, you can only do RETURN ERROR with nothing after it. Seemed like a bug to me and we tried "fixing"it when we released SEH but the change in behavior broke some customer applications so we backed it out.
"Hursh" is a Saxon word ...