Re: A Modest Proposal

[Henrik Nordberg <HNordberg@lbl.gov>]

David M. Malon wrote:
> 
> -> I propose that accessor functions like PercentComplete, and even things
> -> like minNumEvents, should NOT throw exceptions.
<snip>  

I think the QE should throw exceptions in these cases, but maybe the QO
should catch them and return values instead of re-throwing. The QO has
to catch CORBA related exceptions 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 agree, although I think you are over-doing it. Consider:

try {
cout<<"iterator returned "<<OOI.numFiles()<<" and "<<OOI.numRefs()<<"
refs.";
} catch (...) { handle error }

Not quite as bad as the above senario.
Plus I think we should encourage people to write proper code. Error
handling is a tricky subject, which is why the exception mechanism is so
explicit.
 
>    I am happy to propose that users wrap query construction, estimation, and
>    execution in try/catch blocks, but simple accessors?

Well, since all requests to the SM components may throw (atleast CORBA
system exceptions) the user code has to handle exceptions anyway. Unless
it is OK to receive a bogus value because the network is down. I think
there has to be a way for the user code to know if the values it gets
are valid or not. Do you want to use negative values or something else
to show that something went wrong?

Regards, Henrik
___________________________________________________________
Henrik Nordberg <HNordberg@lbl.gov> http://nordberg.lbl.gov
Scientific Data Management Research Group
Lawrence Berkeley Laboratory