[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A Modest Proposal
I'm in the middle of tracking down a bug in which the Query Object - Query
Estimator duo throw an exception when PercentComplete() is invoked--someone
thinks the query state has become invalid before the iterator has received
all the data. That's not what I'm writing about, but it motivates this
note.
-> I propose that accessor functions like PercentComplete, and even things
-> like minNumEvents, should NOT throw exceptions.
They should instead return "innocuous" values, and we should document our
way out of any inconsistencies. I realize that one could make an
argument for notifying the user that her query doesn't exist, rather
than telling her that it's 0% complete, but if we force a user to wrap
every effort to retrieve an integer from our components in try/catch blocks,
and kill her code whenever anything goes even slightly awry if she fails to
do so, we will win no fans (...and I want people to LIKE us; well, me,
anyway).
Consider the single line
cout<<"iterator returned "<<OOI.numFiles()<<" and "<<OOI.numRefs()<<" refs.";
Do we want to require that the user write:
************************************************
int nFiles = 0;
int nRefs = 0;
cout<<"iterator returned ";
try {
nFiles = OOI.numFiles();
}
catch(...) {
// "Switch" block to set nFiles or terminate cleanly, depending upon the
// particular exception, should go here.
}
cout<<nFiles<<" and ";
try {
nRefs = OOI.numRefs();
}
catch(...) {
// "Switch" block to set nFiles or terminate cleanly, depending upon the
// particular exception, should go here.
}
cout<<nRefs<<" refs.";
************************************************
Imagine doing this every time you want to touch a datum! No one wants
to code like this, and I don't believe that doing so improves software
quality.
I am happy to propose that users wrap query construction, estimation, and
execution in try/catch blocks, but simple accessors?
What do you think?
David