[Koha-patches] [PATCH 2/2] Bug 5415 Let calls of SimpleSearch utilize considtent interface

Clay Fouts cfouts at liblime.com
Thu Nov 18 18:22:30 CET 2010


On Thu, Nov 18, 2010 at 9:05 AM, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> On Thu, Nov 18, 2010 at 11:37 AM, Clay Fouts <cfouts at liblime.com> wrote:
> > The die() in the above code is perfectly legitimate because the routine
> does
> > not know how to handle the error gracefully.
>
> I disagree. Rather than using a die(), take the time to code the
> graceful error trapping. die() in most cases is the lazy way out,
> imho.
>

A properly handled die() is just as if not more graceful than checking
return values. Using tools like Try::Tiny or even a plain old eval{} give
the developer lots of options as to how to deal with a value. Also, die()
makes sure that intermediary layers that *don't* check for and percolate
error values don't get in the way of upper layers being able to check for
it. In Koha's current state of error checking, this latter point is crucial.



> > I cannot count the number of
> > hours I've had to spend tracking a bug back to its source through all
> sorts
> > of twists and turns because Koha did not die() when it couldn't figure
> out
> > how to handle the original error and simply warn()ed about it or, more
> > frequently, opted not to check for errors at all.
>
> This is due more so to poor coding than anything else. Always handle
> errors. If the coder can anticipate places in the code where errors
> are likely to occur with enough accuracy to warrant a die() then there
> is no reason not to go ahead and code graceful error trapping.
>

Are you going to reject code that doesn't check every last possible error
status?



> I agree with this in theory. However, what we must compel ourselves to
> do is handle errors, not die().
>

That's the whole purpose of eval{}.



> I don't see anything in this thread which would suggest that we "let
> errors propagate throughout the system." On the contrary, the entire
> thread seems to revolve around the best way to prevent that while
> giving useful information to the user and maintaining maximum
> availability of the rest of the system.
>
> I tend to shy away from software that presents solid color screens
> with cryptic information when it crashes... ;-)
>

I tend to shy away from software that allows defective state to lazily
propagate throughout the system.

Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-patches/attachments/20101118/68e3fb09/attachment-0001.htm>


More information about the Koha-patches mailing list