There are many places where a console.log() is used instead of send the error to the user, this can cause silent errors and user would not know that he should retry the command. However, there are places where console.log() is the unique option, like when bot is initializing, and in those cases is ok to leave only console logs to let the host of the bot to know what is the error.
We have not a consistent way to handle errors on the bot. Would be great to have an easy way to report an error, that end in the same way for the most of cases. I think we should consider two cases:
When we can send a replication to the user
When we can't send a replication to the user
My proposals are:
When we can send a replication to the user
Send a friendly error to the user, or in case we have not a friendly error because was a uncaught error, send a message like "There were an unexpected error, try again or communicate with bot host to get full log of the error"
Make a console log of full error for discord bot's host
When we can't send a replication to the user
Display the error to the discord bot's host through console.log
Checklist
This issue can be closed when the following tasks are complete:
[ ] There is any centralized way to report errors that automatically send full log through console log and try to send a ephemeral message to the user that invoke the command. (Desirable but not mandatory)
[ ] It is considered the two cases: When we can send a replication to the user and When we can not send a replication to the user
Explanation
There are many places where a
console.log()is used instead of send the error to the user, this can cause silent errors and user would not know that he should retry the command. However, there are places whereconsole.log()is the unique option, like when bot is initializing, and in those cases is ok to leave only console logs to let the host of the bot to know what is the error.We have not a consistent way to handle errors on the bot. Would be great to have an easy way to report an error, that end in the same way for the most of cases. I think we should consider two cases:
My proposals are:
When we can send a replication to the user
When we can't send a replication to the user
Checklist
This issue can be closed when the following tasks are complete:
When we can send a replication to the userandWhen we can not send a replication to the user