Boost logo

Boost :

From: Keith Burton (kb_at_[hidden])
Date: 2002-09-24 01:14:46

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of Beman Dawes
> Sent: 23 September 2002 20:13
> To: boost_at_[hidden]; boost_at_[hidden]
> Subject: Re: [boost] Filesystem Library --- exceptions
> At 04:35 AM 9/23/2002, Vladimir Prus wrote:
> Volodya,
> >I'm starting to think that exceptions thrown by the filesystem
> >are too coarse grained --- there is many types of errors, all of
> >result in the same class thrown, and the only way to tell what
> >is to look at 'what()' results.
> >
> >To be concrete, suppose I call 'rename' and it throws. There are at
> >least to reasons of failure: (1) source file does not exist and (2)
> >source and destination are on different drives/filesystems. In the
> >second case I'd want to call 'copy', followed by 'remove'. However,
> >can I detect that the second case caused the error?
> Notice that filesystem_error has a public member error() which returns
> system error code if there is one. But I don't think that solves the
> problem you are talking about since it isn't a portable return value.
> design was inherited from the old dir_it library, IIRC.)
> Digression: Most of the filesystem function Throws clauses mention one
> two conditions which always cause exceptions. But there are a bunch
> other operating system specific conditions ("don't have the right
> permissions", "O/S is out of some resource", etc.) which can also
> exceptions.
> Maybe we could identify a few of the very most common conditions
> not
> found"), and supply exceptions derived from filesystem_error for
> those. Anything else would just throw filesystem_error.
> Would that solve the problem?
The example quoted would be solved by provision of a move operation.
The problem of decoding rename errors to decide whether a copy is
worthwhile is the primary reason for its inclusion. An important
secondary reason is the significant changes in the semantics of the
WIN32 MoveFile function between the various implementations.
I would prefer move to be implemented but as an alternative a bool
return from rename indicating whether a copy is worth attempting may be
a viable option.

I have attempted to classify the WIN32 error codes into a small set and
can therefore wholeheartedly *not* recommend this course of action.

I have not found any other cases where exception decoding was not
equivalent to exists() and / or is_directory() but I have only been
using WIN32.


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