From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-23 14:12:42
At 04:35 AM 9/23/2002, Vladimir Prus wrote:
>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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk