Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-20 11:25:49

At 09:48 AM 3/20/2002, Brey, Edward D wrote:

>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
>which cleans up anyway, but a program that is exiting wants to do the
>cleanup that it can.
>To solve this problem, I propose that the file IO functions be nested in
>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
>be states variables set as to which errors are reported and/or throw, if
>such flexibility is necessary (I'm not sure).

My initial reaction is that errors are best handled by the traditional
exception mechanism, but I'll try to keep an open mind.

Part of the rationale for Predicate versions of some of the composite
operations like prunes/copies is that users can express exactly what files
to work on. For example, prune( "my_dir", !is_read_only(_1) ), if
read-only files should be skipped.


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