RE: [boost] Filesystem Library --- exceptions

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

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto: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
library
>  >are too coarse grained --- there is many types of errors, all of
them
>  >result in the same class thrown, and the only way to tell what
happened
>  >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,
how
>  >can I detect that the second case caused the error?
> 
> Notice that filesystem_error has a public member error() which returns
the
> 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.
(The
> design was inherited from the old dir_it library, IIRC.)
> 
> Digression: Most of the filesystem function Throws clauses mention one
or
> two conditions which always cause exceptions.  But there are a bunch
of
> other operating system specific conditions ("don't have the right
> permissions", "O/S is out of some resource", etc.) which can also
cause
> exceptions.
> 
> Maybe we could identify a few of the very most common conditions
("file
> 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.

Keith