Kind of with Rust had a notion of `impl TryDrop` for running destructors that can be unsuccessful. Could handle errors gracefully in Result contexts. Call `.unwrap()` in other contexts. Manually dropping through `try_drop(my_fn())?;`
My understanding is that when `drop(foo)` is called, the destructor is run. This can be done manually, or more commonly it happens automatically when the value goes out of scope. `try_drop(foo)?` would be the manual, fallible equivalent. But provides a Result escape hatch
-
-
`drop(foo)` is literally `fn drop<T>(x: T) {}`. It's a no-op function, it works by letting the value fall out of scope.
-
Right. But it's not a no-op for Mutexes, DB connections, files, etc. right? That's more the angle I'm thinking about. Would there be a way to handle errors in destructors there, but don't force API consumers to remember to copy boilerplate.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.