[Gambas-user] How to return results and status from a function to the calling procedure??

Doriano Blengino doriano.blengino at ...1909...
Mon Dec 8 16:39:41 CET 2008


Benoit Minisini ha scritto:
> On lundi 8 décembre 2008, gambas at ...1938... wrote:
>   
>> Hi List,
>>
>> stupid question.
>> What I wanted to do is
>> - call a function and check if all went OK (True/False)
>> - If True get the result and go on.
>> - If False do some error managemen
>>
>> In principle it is an easy task, but:
>> - Using global vars is (citation): "Poor programming practise" ;-)  (no
>> offense)
>> - Using ByRef is slower then copy the content
>>
>> So, what's the best, cleanest or preferred way to do it in Gambas?
>>
>> Greetz
>> Stevie
>>
>>     
>
> If "all was not ok" means that there was an error, then you should use 
> Error.Raise() and error management.
>
> If "all was not ok" is actually normal, then your function should return a 
> boolean that will tell you the result.
>
> If your function also return a value, then you can use one of the value to 
> indicate a problem. For example, a function that returns a Date can return 
> NULL for errors.
>
> If you can't use one of the value to indicate an error, then you must do 
> something else!
>   
"Poor programming practices" exist only when the programmer has no good 
reasons to do so...
GOTOs, for example, are normally considered bad, but sometimes an awful 
goto is clearer, easier and faster than anything else.

So, in your case, a function returning a boolean or an integer error 
code, and having a reference parameter (byval) for the actual result if 
any, could be the best. If you are really worried about speed, then a 
global variable (if faster), should not be regreted.
I am not so deep inside Gambas, but normally raise and catch 
(try/except) are really slow (I think, more than a byval parameter). If 
it is relatively rare that a true error happens in your code, then a 
raise/catch should be the right way to go.

At any extent, no methods are perfect. One can be slower but clearer, 
the other more robust, the other fast but obscure... but normally I 
would neglect speed and go for the clearest one.

Cheers,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."





More information about the User mailing list