belm0
commented
6 years ago 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).
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.