# \[Idea\] \`#\[fallible\_drop\]\` attribute for let statements

**URL:** https://internals.rust-lang.org/t/idea-fallible-drop-attribute-for-let-statements/19680
**Category:** language design
**Created:** [October 10, 2023, 11:19am UTC](https://internals.rust-lang.org/t/idea-fallible-drop-attribute-for-let-statements/19680 "2023-10-10T11:19:47Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![pdolezal](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pdolezal/32/7137_2.png) [@pdolezal](https://internals.rust-lang.org/u/pdolezal)
#### Post date: [October 11, 2023, 6:50am UTC](https://internals.rust-lang.org/t/idea-fallible-drop-attribute-for-let-statements/19680/6 "2023-10-11T06:50:33Z")

</div>

I'd like to point out to a [discussion here](https://internals.rust-lang.org/t/question-closing-resources-like-std-write/13169/6) (originated by myself 🥸 ) where a hypothetical `TryDrop` trait was considered:

```rust
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:

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

---

_[View the full topic](https://internals.rust-lang.org/t/idea-fallible-drop-attribute-for-let-statements/19680)._