Problem with function return

Problem with function return

[Amgarp]

Hi,

please help me with the following Problem:

Main programm:

type color is (red,gree,blue);

col:color;

col:=some_function(parameter);

Now, "some_function" returns of course a color type,
but when the parameter is bad(e.g. an empty string), an exception will be
raised.

What should the function return then?

Without a return statement in the e-handler there'll be a
Programm_Error.

Is there a way to prevent the line "col:=some_function(parameter);"
to be evaluated, or should it just return "some"(but of course wrong)
value?

Thanks!

Re: Problem with function return

[David Starner]

On Sun, 2 Apr 2000 21:34:59 +0200, Amgarp <PhyrePhox@firemail.de> wrote:
>Hi,
>
>please help me with the following Problem:
>
>Main programm:
>
>type color is (red,gree,blue);
>
>col:color;
>
>col:=some_function(parameter);
>
>Now, "some_function" returns of course a color type,
>but when the parameter is bad(e.g. an empty string), an exception will be
>raised.
>
>What should the function return then?

What is the function? What is the problem?

Possible solutions:

(a) Make type color is (none, red, green, blue) and return none.
It's probably not appropriate in this context, but I can't really
tell. Cf. IEEE 745 floating point numbers for an example (NaN & Inf).

(b) Raise or propogate an exception. Proabably your best solution
in this case. 

(c) Check the input, and only call some_function if the input is
good. I don't like this one, as some_function should still check
the data itself, as long as it takes unstructured data. 

(d) Assert that the data is correct (e.g. using GNAT's pragma Assert)
and if it's not, print an error message and quit. Only appropriate
if parameter does not come from the output and must be correct no
matter what comes in.

Really, the problem admits of many many answers. If you frame the
question in specifics, I can give a specific answer.

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: Problem with function return

[A. Logue]

PhyrePhox@firemail.de (Amgarp) wrote in 
<38e7a0c8$0$17676@businessnews.de.uu.net>:

>Hi,
>
>please help me with the following Problem:
>
>Main programm:
>
>type color is (red,gree,blue);
>
>col:color;
>
>col:=some_function(parameter);
>
>Now, "some_function" returns of course a color type,
>but when the parameter is bad(e.g. an empty string), an exception will be
>raised.
>
>What should the function return then?

At work we have an informal standard to declare a "Nil" kind as the first
kind for all enumerated types.  For example 

type color_kind is (nil, red, green, blue);

This works great in many cases where the return type cannot be determined 
(for whatever reason), simply return a nil kind and let the function's 
clients deal with the result.  i.e.  ignore and carry on, delay and retry, 
etc.  

Re: Problem with function return

[Ray Blaak]

synoptik@home.com (A. Logue) writes:
> At work we have an informal standard to declare a "Nil" kind as the first
> kind for all enumerated types.  For example 
> 
> type color_kind is (nil, red, green, blue);
> 
> This works great in many cases where the return type cannot be determined 
> (for whatever reason), simply return a nil kind and let the function's 
> clients deal with the result.  i.e.  ignore and carry on, delay and retry, 
> etc.  

If nil is used to mean error, then it is actually better to raise an
exception. The client still then has the choice to ignore and carry on, delay
and retry, etc., but the error handling logic is clearly separated from the
normal logic, which makes things more understandable. 

If nil is used to mean "not specified yet", then its role is more useful. It is
a mistake to use it too much, however. I have been on projects where it was
mandated for all enumerated types, complicating logic and test cases for that
extra, often useless value. If the enumeration already sensically expresses all
possible values, the unknown/nil/undefined value is often superfluous.

For example,

 type WeekDay = (Sun, Mon, Tues, Wed, Thurs, Fri, Sat);

There are no other possible values. Now one still might want to express
undefined or unknown, so I would at least do this:

 type WeekDayValue = (Unknown, Sun, Mon, Tues, Wed, Thurs, Fri, Sat);
 subtype WeekDay = WeekDayValue range Sun .. Sat;

I would try to stick to the restricted one as much as possible, and use the
more general one only when necessary (i.e. converting from external inputs,
etc.).

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Problem with function return

[Robert Dewar]

In article <m3aejb27iv.fsf@blight.transcend.org>,
  Ray Blaak <blaak@infomatch.com> wrote:

> If nil is used to mean error, then it is actually better to
> raise an exception.

>>more good stuff snipped<<

As you know from my previous post I basically agree with this,
however it is worth reminding ourselves that an unhandled
exception can be a nasty thing (remember the Ariane!)

As Ray said, the critical thing is to be sure of the interface
at an abstract level.




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Problem with function return

[Robert Dewar]

In article <8F0AB9788synoptikdamudderfuck@news>,
  synoptik@home.com (A. Logue) wrote:

> At work we have an informal standard to declare a "Nil" kind
> as the first kind for all enumerated types.  For example

>    type color_kind is (nil, red, green, blue);

> This works great in many cases where the return type cannot be
> determined
> (for whatever reason), simply return a nil kind and let the
> function's

This seems a bad idea to me, it will result in C-like errors
of the caller forgetting to check for an error, yes it may
be caught, but it is much to easy for it to get swallowed
up, e.g. by the else clause of an if.

Much better to raise an exception. if the caller wants to handle
it they can put an exception handler at the call site. If they
don't want to handle it, or more likely they forget, then the
exception gets raised and unhandled, which is often better than
blindly carrying on!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Problem with function return

[Mats Weber]

Robert Dewar wrote:

> >    type color_kind is (nil, red, green, blue);

> This seems a bad idea to me, it will result in C-like errors
> of the caller forgetting to check for an error, yes it may
> be caught, but it is much to easy for it to get swallowed
> up, e.g. by the else clause of an if.
> 
> Much better to raise an exception. if the caller wants to handle
> it they can put an exception handler at the call site. If they
> don't want to handle it, or more likely they forget, then the
> exception gets raised and unhandled, which is often better than
> blindly carrying on!

Of course an exception is best when feasible, but I have used the Nil
technique quite often when I need the enumerated type as a discriminant
and a default value is required, as in:

type R (Color : Color_Kind := None) is
   record
      case Color is
         when None =>
            null;
         when Red =>
            ....
      end case;
   end record;