On Mon, 16 Apr 2001, John F. Chandler wrote:
> Perry wrote:
> > > Ok, how should we handle NULL PSTRINGs ?
> > > They aren't handled very well right now.
> > >
> > > __name() will make a NULL PSTRING if it can't find
> > > the person (indi == NULL), eg if you hit enter at the
> > > getindi prompt (which is what I did and what led me here)
>
> The current behavior of LL demands that each report program check for
> this possible outcome. There are really two questions here: should
> that requirement be lifted, and should __name() do things differently?
>
> I would argue that reports programs should always check for null input
> to getindi, no matter what, since the user always has the option of
> hitting enter at that point. There is no way at all for LL to screen
> the report program writer from this aspect of interaction with the user.
> Therefore, the second question should be viewed in the context of doing
> the best thing, not necessarily the purest thing. All in all, I'd say
> the name function should issue an error message and halt if it gets a
> NULL instead of a person. It's hard to imagine getting a correct
> result from the report program if this ever happens, so why prolong the
> agony?
>
> Matt wrote:
> > Hence, any invalid input to a function should return an appropriate
> > zero-valued data type (ie __name should return an empty PSTRING, not a
> > NULL PSTRING).
>
> That's the purest thing, I agree, but not necessarily the best thing.
>
> > Each function should be using ASSERT to ensure that the
> > inputs are not NULL (well-formed input), and should also be robust enough
> > to handle "empty" inputs.
>
> Isn't ASSERT a bit too draconian? Whenever an ASSERT fails, LL itself
> screeches to a halt. This is not the sort of diagnostic that a report
> programmer needs. If a NULL input implies a report programmer error,
> with no possibility of recovery, then an immediate error message is the
> right response. Otherwise, robust handling is the way to go.
Perhaps ASSERT is a bit overboard, but an ASSERT-like function that halts
the report with a meaningful error message might be best.
Perhaps something like "invalid input to argument x of function yyy at
line z of report abcd"
--
Matt Emmerton
|