[Idea] `#[fallible_drop]` attribute for let statements

language design
6

I'd like to point out to a discussion here (originated by myself :disguised_face: ) where a hypothetical TryDrop trait was considered:

trait TryDrop {
    type Result;
    fn try_drop(self) -> Self::Result;
}

The idea was using it for the cases when the outcome of the Drop would be interesting or important. It would be invoked manually and the caller would get the Result then to see if there is anything to report, a need to run a recovery action, or whatever else. The Err result might even return self back if there is a reasonable recovery action… and the caller could then decide if there is anything to do, or just can that returned self pass to the usual, silent Drop.

I suppose it is not useful for any async Drop ideas, let alone if you have some ideas how to cope with that in a more general effect system. But perhaps it might be worth alone, maybe a building block for something more advanced, which could be available sooner.

Regarding the aggregated Error::source, I think you are right. Just sharing my 2 cents: Java has try-with-resources blocks:

try (var resource = openMyFile()) {
   // Do stuff
} // Here resource is closed

Here, resource must implement the AutoCloseable interface and its close method is invoked always at the end of the block. If there is an error, an exception is thrown. And now the interesting part: an exception may be raised in the try block and should be propagated, but closing the resource throws an exception too – this is the situation that you mention. Or you have multiple resources and some of them fails to close. In any case, these secondary exceptions are attached as so called suppressed exceptions, i.e., not direct causes, but something that happened when cleaning up… so the information about failed clean-up is not lost.

Hence, Java implements actually a sort of error tree as you mentioned, we have a precedence. Thus I agree that Error could support something similar and should not be limited to a single "source".

Maybe… there might be an idiom using with TryDrop how to collect and combine the results of that explicit clean-up into such an aggregated Error.

1 Like