Boost logo

Boost :

From: Jason Stewart (jstewart_at_[hidden])
Date: 2002-03-20 10:11:05

One of the original goals of this project was to make it easier to write
"script-like" programs. One of the things that makes it easy to write
scripts in perl is that you can ignore things that are not important to
you. I agree that it is a Good-Thing to force checking of errors and
exceptions are a good way to do this. However, what Robert has suggested (I
think) is two functions. One throws an exception if the file is not there,
the other just returns success/failure. This meets both requirements above.
It is possible to write robust programs and it is possible to write quick

Jason Stewart

At 09:48 AM 3/20/2002 -0500, you wrote:
> > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> >
> > > useful to bail out and go into diagnostic mode. The same
> > > argument can be
> > > made for removal. Often you can get by with ignoring the
> > > problem, but by
> > > triggering an error and addressing it, you get the
> > > opportunity to dig in and
> > > get to the bottom of an otherwise masked problem.
> >
> > I never said we should ignore the condition. I suggested
> > that remove()
> > return an indicator as to whether the file was actually
> > remove() or didn't
> > exist. One can write code to inspect the return value if
> > that's condition
> > is interesting.
>The problems with requiring programmer to inspect the return value are
>well-known and were a great motivation for the invention of exceptions. I
>think regressing to a check-the-return-code pattern would be a bad idea
>unless we knew that it would be very rare when anyone cared. However, I
>think that in many applications, overall system robustness and diagnostics
>would benefit from asserting that the remove was successful, and it would be
>good to make this as easy for the programmer as possible, lest we be tempted
>to be lazy and just skip it (ignore the return value).
>What makes this dilemma trickier than most is that often, even though we
>want to know about the problem, we don't really want to interrupt our
>control flow. That is, we want to limp on as best as we can. That's not
>the case in my Python build script, since I can always spawn another build
>which cleans up anyway, but a program that is exiting wants to do the best
>cleanup that it can.
>To solve this problem, I propose that the file IO functions be nested in a
>error notification context. Basically, it would be like this:
>class file_io_context {
> public: // Setup
> void set_listener( void (* listener)(error_type) );
> public: // File manipulation
> void remove(string filename);
>Now if remove fails, it calls the registered listener. Likewise there could
>be states variables set as to which errors are reported and/or throw, if
>such flexibility is necessary (I'm not sure).
> > > In my Python script for performing the formal builds of our
> > > software, I am
> > > quite happy when the script throws an exception when I tell
> > > it to remove a
> > > file that I expect should be there but isn't. It's basically
> > > like getting a
> > > free assertion in the code.
> >
> > I'd hate having to write, or even execute code that ignores
> > an exception
> > raised by such a common and (nearly always) benign condition.
> > Throwing an exception is too heavyweight for something like this.
>This is a good demonstration that there are at least two different use cases
>for the file IO library. Setting up try blocks for each remove is too much
>coding. Likewise, checking the return value from each remove is too much
>coding. Having a remove and a remove_if_exists helps, but it doesn't handle
>the case where you want to be notified of the problem but not have it
>interrupt the program flow. For that you need an error notification
>Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at