Add error in constant and removed all panics

[MaxThom]

It would be nice if all the errors where defined and public so we could reference them in the code instead of string checking.

Moreover, I saw a few panics in the codebase, would be nice to get rid of thoses. I dont think any librairy should have panics.

[mumoshu]

Hi again @MaxThom!

Regarding specific error types, let me link #96 (comment).

We need it, but it may take some time. So, I've summarized why it takes time and what we can do today.
Almost all errors are not "actionable," in the sense that they can't be auto-corrected and retried. You should log errors and let the consumer of your application retry. The only exception I can think of is network and transport-related errors coming up from gorilla/websocket and net.Conn, which could be diagnosed by using errors.As or errors.Is, assuming we aren't doing something wrong...

If you can't drill down to the root of the error by unwrapping, I think we can file it as an issue and fix one by one.

Furthermore, we could try adding our own TransientError type that wraps every "known" transient errors coming up from implementation details like gorilla/websocket, net.Conn, and so on. I don't think we can make its first version perfect, but adding it early and enhancing it to cover more transient errors as we discover them would work.

WDYT?

[MaxThom]

yea sound like a good idea to me, mainly on the errors you can act on like transient. Have defined errors in a go library always feel a more premium and high quality library