Does this have something to do with StdFS Tempdir ignoring errors on drop? That sure looks like a special case of this general problem: Dropping a value, while conveniently implicit, allows no side channel through which to deploy error information when something goes wrong.
As I stated in that thread, a flexible solution would involve adding a handler callback on creation of the Writer/Reader.
Requiring close() to handle errors fails to be as convenient as RAII. Likewise requiring an explicit guard. A callback that could be an empty function to opt out of handling drop errors seems the optimum in terms of user experience.
The callback may even return some value to the drop code to decide what to do next (like abort / retry / ignore?).
Now let me be the first to admit that using a callback is not without problems. For example, what should we do if the callback panics? Should we require the callback to run in its own task? — no, because that would add a dependendy to IO that may or may not be available depending on the system we deploy on. Also the callback would block the drop.
I still think that this problem is inherent in the nature of any side channel for error informations. If handling the error panics or fails to return, the program was wrong in the first place.