* Problem with function return @ 2000-04-02 0:00 Amgarp 2000-04-02 0:00 ` David Starner 2000-04-03 0:00 ` A. Logue 0 siblings, 2 replies; 7+ messages in thread From: Amgarp @ 2000-04-02 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with function return 2000-04-02 0:00 Problem with function return Amgarp @ 2000-04-02 0:00 ` David Starner 2000-04-03 0:00 ` A. Logue 1 sibling, 0 replies; 7+ messages in thread From: David Starner @ 2000-04-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with function return 2000-04-02 0:00 Problem with function return Amgarp 2000-04-02 0:00 ` David Starner @ 2000-04-03 0:00 ` A. Logue 2000-04-02 0:00 ` Ray Blaak 2000-04-03 0:00 ` Robert Dewar 1 sibling, 2 replies; 7+ messages in thread From: A. Logue @ 2000-04-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with function return 2000-04-03 0:00 ` A. Logue @ 2000-04-02 0:00 ` Ray Blaak 2000-04-03 0:00 ` Robert Dewar 2000-04-03 0:00 ` Robert Dewar 1 sibling, 1 reply; 7+ messages in thread From: Ray Blaak @ 2000-04-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with function return 2000-04-02 0:00 ` Ray Blaak @ 2000-04-03 0:00 ` Robert Dewar 0 siblings, 0 replies; 7+ messages in thread From: Robert Dewar @ 2000-04-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with function return 2000-04-03 0:00 ` A. Logue 2000-04-02 0:00 ` Ray Blaak @ 2000-04-03 0:00 ` Robert Dewar 2000-04-03 0:00 ` Mats Weber 1 sibling, 1 reply; 7+ messages in thread From: Robert Dewar @ 2000-04-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Problem with function return 2000-04-03 0:00 ` Robert Dewar @ 2000-04-03 0:00 ` Mats Weber 0 siblings, 0 replies; 7+ messages in thread From: Mats Weber @ 2000-04-03 0:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-04-03 0:00 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-02 0:00 Problem with function return Amgarp 2000-04-02 0:00 ` David Starner 2000-04-03 0:00 ` A. Logue 2000-04-02 0:00 ` Ray Blaak 2000-04-03 0:00 ` Robert Dewar 2000-04-03 0:00 ` Robert Dewar 2000-04-03 0:00 ` Mats Weber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox