× Unhandled Rejection (Error): There is already an encoder stored which handles exactly the same mime types.
Closed this issue · 5 comments
Hi, I'm having an issue when I want to use the audio/wav mimetype.
× Unhandled Rejection (Error): There is already an encoder stored which handles exactly the same mime types.
Hi @bobberg, knowing only the error message I would guess that you call register() multiples times with the same encoder.
Can you share the part of your code which triggers the error?
Hi @chrisguttandin thank you for the library! Should it be an exception in this case? Why is it not a warning? Also what do you think about making this error actionable?
Example "There is already an encoder stored which handles exactly the same mime types. Make sure that you call register() only once with the same encoder"
I can make a PR.
Hi @kubk, thanks for your feedback. However, I personally still think it better should be an error.
It's of course highly subjective but I think it should not fail silently. If it would it would be okay to have production code which calls register() over and over again. Each time the message has to travel to the Web Worker and back again which unnecessarily delays everything else.
But I think the strongest argument is that there could potentially be a clash. Let says someone uses two encoders which both pretend to encode the same mime type. In that case the first one will be registered und always gets used even though the second one was registered as well and no error was thrown. I think this could be very confusing.
Last but not least I think an error can be turned into a warning message in the console by a user of this package but doing the opposite is not so trivial.
I tried to balance the length of the error message with its usefulness. The reason why I try to keep error messages as short as possible is that they can't get minified. I would love to have a system which allows for very long error messages but turns them into error codes in production code. That system would need to use something like source maps for errors to turn them into human readable messages again.
Sorry for that lengthy answer. I hope it makes sense.
@chrisguttandin Thank you for the detailed answer. Let's keep the error message as is in this case. Future visitors can search for a solution in GitHub issues the same way I did. You have already posted a working solution (at least for me) and I think the issue can be closed.
Okay, I'm going to close this for now. I assume @bobberg is okay with that, too. The issue has been stale for a while.