More close Considerations

[Aidan63]

Follow up from my comment about the state of objects after closing.

What is the state of objects after the user has issued a close call but before the callback has been invoked?

file.close((_, error) -> trace("closed"));
file.write(myBuffer, 0, myBuffer.length, (count, error) -> trace("???"));

In the above example a write is issued after close is called, should this also error, but with what? Reuse the proposed ObjectClosedException? introduce an ObjectClosingException?

The next question is what is the user expected to do if they get a close error? Try again? Are we making guarentees that if closing fails the object is still perfectly usable, or is it in some weird unknowable state where maybe its usable, maybe some of its resources have been cleaned. From a libuv point of view uv_close will always succeed and cannot return an error (either in its callback or from the call itself). The only "closing" related call which might fail is uv_shutdown which flushes any pending writes, but examples online seem to go straight to calling uv_close if this returns a failure.

I think the following would be best to remove any confusion.

• The moment close is called the object is considered "closed" and any further access will result in ObjectCloseException results.
• Change the close callback signature to not have an error, treat it as the special case it is with just a simple Void->Void callback (Not sure how this would effect any coroutine integration plans).
• Calling close multiple times could be defined as a special case where its allowed and doesn't result in any error and will just do nothing if already closed.