Skip to content

Conversation

belm0
Copy link
Contributor

@belm0 belm0 commented Apr 3, 2018

A failed connection is normal (more likely a connectivity issue than programming error) so the library should avoid logging. A real app needs to handle connectivity issues and periodically retry connections, and this logging at every attempt wouldn't be too useful.

A failed connection is normal (more likely a connectivity issue than programming error) so the library should avoid logging.  A real app needs to handle connectivity issues and periodically retry connections, and this logging at every attempt wouldn't be too useful.
@belm0
Copy link
Contributor Author

belm0 commented Apr 3, 2018

The remaining logged messages all appear more severe (unexpected state, invalid URL length, parsing error, etc.) so it seems reasonable to leave them.

The bigger question is whether user of the library needs to discern among the various errors in creating a connection, especially between routine connectivity issues (i.e. you want to retry) and bad arguments, parse errors, etc. (i.e. you want to fail). It could be done by error enums or exception classes. At which point all error messages should probably be put under control of the library user (e.g. as part of exception option, returned as string, or some error callback).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant