HP3000-L Archives

December 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Dirickson <[log in to unmask]>
Reply To:
Steve Dirickson <[log in to unmask]>
Date:
Tue, 25 Dec 2001 22:18:35 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
> >However, this error indicates a more serious condition: a
programmer
> >who holds error- and status-checking in such low esteem that s/he
is
> >attempting to close a database that was not successfully
> opened. Since
> >opening a database is pretty fundamental to the operation in most
> >HP3000-based applications, I'd be more than a little concerned
about
> >the quality of a program that is flummoxed by a failed DBOPEN.
>
> Or it could indicate the opposite: a programmer who's very
> careful and
> wants to make sure that a data base is closed cleanly. That
> means s/he
> puts the DBCLOSE in the termination path of the program so that it's
> always executed, no matter what other failures (database or
> logic) the
> program detects. This results in a spurious error message if
> the thing
> that failed is the DBOPEN, but otherwise, it's sound
> practice. The logic
> necessary to skip the close if the open wasn't successful
> might just be
> viewed as a pointless complication that adds another
> potential point of failure.

Interesting viewpoint. I am pretty rigorous about not writing code
that can't succeed, particularly when that guaranteed failure will
generate error messages, abnormal terminations, or other in-your-face
side effects. In my book, a DBCLOSE on an unopened database falls into
that "can't ever succeed" category. Also, "The logic necessary to skip
the close if the open wasn't successful" is the same logic as that
required to not do all the other things the program would normally do
with the database if it had been successfully opened, so I don't see
how it can be cleanly avoided. A matter of style, I guess.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2