Re: [boost] Filesystem Library --- exceptions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-24 02:41:36

Beman,

>  >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.)

Yes, system specific return code does not help much.

> 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.

Right. And contrary to Keith Burton, I think that exceptions of both 
kinds can be meaningfully used -- I would not like to call several fs 
functions just to determine what was the cause of the error.

System specific errors are less usefull here -- even if I know that 
operation failed because target directory is read only, there's 
currently no way to add write permission, for example. But as more 
functionality is added, more exceptions types can become usefull.

> 
> 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.

That's right way to go. Experience will show which derived exceptions 
types are needed. At the minimum, we need to support rename use case 
I've described (unless 'move' is really added).

- Volodya