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