From: Godmar Back (gback@cs.utah.edu)
Date: Mon Nov 16 1998 - 11:14:14 EST
I see what you're saying, you lose the possible NULL return value.
This is not a problem for the functions I changed, but if a function
wanted to allow NULL as a valid return value, then that function will
have to coded that way. What I outlined were the general feeling,
not a fixed rule applied to each and every one function.
- Godmar
>
> On Nov 16, 1998, Godmar Back <gback@cs.utah.edu> wrote:
>
> >> Anyway, I still don't like very much the idea of modifying the return
> >> values of the functions. Can't we just rely on the fact that, if the
> >> class name is NULL, no exception was thrown, otherwise the returned
> >> value is meaningless?
>
> > I'm not sure what you mean.
>
> My suggestion is that the errorInfo classname would be initialized to
> NULL, and, after calling a function that might have modified it, you'd
> just check whether classname is still NULL. If not, an exception was
> thrown. Then, you wouldn't have to create return values for the
> functions. After all, sometimes a NULL might be a valid return
> value.
>
> > I reused the return value where functions had a return value (getClass,
> > for instance), I added a return value for functions returning void,
> > processClass for instance. There is no way around that.
>
> My suggestion is a way around that. But not using this approach is
> fine, as long as there is no possible ambiguity in the return values.
> I agree that your approach is faster, it's just that it might not be
> completely safe if there were any possibility that the returned value
> might be taken as an exception condition when in fact it is just a
> regular return value.
>
> --
> Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
> oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org.au}
> Universidade Estadual de Campinas, SP, Brasil
>
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:03 EDT