[haiku-development] Re: BPath::Append() resets the original path in case of failure.
- From: "Bruno Albuquerque" <bga@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 25 Feb 2009 22:47:30
On Wed, 25 Feb 2009 22:43:10 +0100 CET, Axel Dörfler said:
> I'm not even sure that it would be a good idea to keep the object in
> a
> sane state after such a failure - after all, it definitely is not in
> the state you would want it to. If you don't care and just continue
> to
> use it, you would probably not access the file you originally
> intended
> to -- letting all subsequent actions fail as well seems to be the
> preferred thing that should happen.
Append() returns an error on failure. It is the caller's responsibility
to check it. If it does not, then it it is a bug. I do understand that
we inherited from the BeOS API and that this was like that there (and,
as Ingo pointed out, it is like that throughout the storage kit) but it
definitelly does noit make it right. The behaviour is completelly non-
intuitive and does not make any real sense. The result of an Append()
operation failing should be simply that nothing will be appended.
Just to mention an example, realloc() is equivalent semantically to an
append operation. In case of any failure, realloc() simply does not do
anything to the original memory block. I am pretty sure this can also
be said about almost virtually any append-like operations everywhere.
> Of course one could change the setters to be non-destructive in case
> of
> failure, but I don't really see any benefit in doing so. If you still
> need the original object as is, you would need to copy it before,
> anyway.
I am not saying we should change it now but considering doing it at
some point is a good thing in my opinion. If not for anything else,
simply because that would make it closer to what one would intuitively
expect.
-Bruno
Other related posts:
