Closed abarisani closed 9 years ago
I've checked for nil pointer dereference but I wonder if an error needs to be returned at all, or just have a message logged.
A StopListening function, executed on a non listening instance, should return an error imho. As you are building a library you should avoid "messages" as the sole mean of feedback to the user and provide functional means to do so.
Imho I would avoid logging and/or "messages" in your library and leave the task of showing them to the caller of the library, and return them as errors when appropriate.
Anyway my primary need for now is not having StopListener crashing when invoked on a non started instance.
Thanks! :)
I agree an API should return errors. Logging messages are orthogonal to that, and are useful when debugging the package. In this particular case, when the error is a misuse of the API and only occurs until the developer fixes the app, a message could be enough, just like we panic if a certain callback is not implemented. But I will add an error anyway, it is better that way :)
While it is certainly recommended for StartListening() callers to ensure its execution without errors it would be ideal for StopListening() to avoid triggering a null pointer dereference (wsconn.closing) when invoked after errors in StartListening().
I recommend to check for the validity of wsconn in StopListening() and return an error in case.
Thanks!