Sorry, that wasn't what I meant.

Marking a flow as broken when you get Out_of_memory is a perfectly fine thing to do - it is very likely to be in a bad state and should not be used again.

Rather, I meant we want to be able to distinguish between:

• The system is currently out of memory (try dropping some caches), and
• This flow cannot be used because the system was previously out of memory (close it and open a new one).

Out_of_memory was just an example of an exception that is confusing if re-raised later.

Thanks for your comment @talex5, but I think the Out_of_memory exception is really exceptional, and the application should deal with it.There's nothing a library can do -- any further allocation (even for closing streams, etc.) may lead to subsequent failures. Read further on mirage/mirage#1036 if you're interested in why it's bad to catch and hide Out_of_memory.

I agree that libraries shouldn't be suppressing Out_of_memory (which the Mirage libraries did), but recording it and immediately raising it again is OK.

What I don't like is having special cases (e.g. what about Stack_overflow or Assert_failure?). The application should always get to see unexpected exceptions.

So, I think TLS should either store all unknown exceptions or none of them, and report it to the application in all cases.

The main tricky case is read, which may successfully read some data but then fail to write. Currently it reports success and then reports the write failure later.

There's nothing a library can do -- any further allocation (even for closing streams, etc.) may lead to subsequent failures.

That's not a big problem. It's responding to an error in a complex operation (e.g. reading TLS data) by trying to perform a simpler one (e.g. marking the flow as failed). If that runs out of memory too, it will still get reported.