rfcs
rfcs copied to clipboard
ponylang
Added RFC for network errors handling
I'm not in favor of new methods. I'd rather use existing failure methods that already exist. We are pre-1.0, this is a small change, backwards compatibility isn't a concern.
The "How we teach this" depends on functionality that doesn't exist... deprecation annotation. So, I don't consider that to be a good answer.
I think it would be reasonable to update the doc strings for the given methods to account for the methods as well as add example code (or expand as the case maybe) for TCPConnection, UDPSocket and TCPListener to show usage of handling errors.
Can you detail all the different SocketErrors we need to account for in the union type and what they would map to? There isn't enough here to implement. A complete mapping that is agreed upon would allow anyone to pick up and implement this.
Why not have the error reason be a parameter of connect_failed and not_listening, as mentioned in Alternatives? I don't really see how that would be "less smooth" and there are several advantages. I think having the error code as a parameter is less error prone because the method signature reminds you to check the reason, and it avoids setting a field on every operation in the implementation.
the markdown formatting on this is off and currently kind of hard to read as half of it is in italics
I'm not in favor of this RFC and the errno value. I'd want to see error values passed to notify methods as appropriate.
Changing notifiers API is of course less smooth because it breaks existing code which uses "net" package. If keeping existing API is not important, then success and failure callbacks can be joined to single callback with error code provided
As @SeanTAllen said, ensuring backwards compatibility isn't very important until we've hit 1.0. That said, I think we'd want to keep the success and failure callbacks separate since they are expected to take very different actions.
I'd tend to agree with @Praetonus about keeping the callbacks separate - they are really very separate in terms how you want to handle them, and arguably the success case doesn't really need an error code.
Having single callback for connection result will also solve RFC 23, since it will force "net" package users to implement dispatch on error code
I actually like different callbacks as well for success&failure and also error provided in callback, that was the initial proposal in given RFC. So having API like
fun ref not_listening(sock: UDPSocket ref, error: SocketError)
fun ref not_listening(listen: TCPListener ref, error: SocketError)
fun ref connect_failed(conn: TCPConnection ref, error: SocketError)
is most affordable, correct ?
@zevlg yes. i think providing the error to existing methods is a the best approach