-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Centralize error handling #198
Comments
Fyi this is somewhat related to #85, which also mentions we should port over the error handling. |
Hello @ChrisLovering, let's get this rolling. I don't have any feedback at the moment, but I hope to provide some in the near future. |
This seems like quite a nice approach to dealing with this. One that may even be suitable for adding to D.py itself! If you're interested in wokring on this yourself @shtlrs please do go ahead! |
@ChrisLovering I started working on this, and one thing I'm wondering is how'd we want to register handlers ? If we go with option 1, I think the loading can be done synchronously since they're simple classes to setup with no equivalent of |
I think we want it to be something that needs to be called manually, rather than walking them. That way cogs can register error handlers, or in the setup_hook of bots we can register generic handlers. |
Do you mean like we have a cog that's responsible for registering these handlers ?
The way I have it written now, is that the container class needs to have a It's also there because the container exposes a the container's class Container:
def handle_error(...):
for handler in self.handlers]:
if handler.should_handle():
handler.handle()
break
else:
self.default.handle() That way we can solely rely on the |
I'm not sure I fully understand the proposal in this issue, but i'm not sure what the benefit of being able to have lots of error handler classes is. Would it not be simpler to have only a base |
The benefit is to be able to
|
Problem
Currently, all of the error handling is usually done through an
ErrorHandler
Cog.This cog will only handle errors raised from
Text Commands
and will not catch errors raised fromApp Commands
(Slash Commands
andContext Menu Commands
)Solution
The way we can centralize handling for
App Commands
would ideally be by subclassing theCommandTree
class and override theon_error
method, then upon instantiating the bot, will pass this class as an argument to thetree_cls
param.We obviously want to factor out the commun error handling code to avoid duplication, but not at the cost of code simplicity/readability. What this means is that a little bit of duplication is ok instead of having alot of python magic thrown at it.
I wanted to discuss the approach I had in mind before I start working on this.
Idea
chain of error handlers
Once the previous is done, the
ErrorHandler
cog and theCommandTree
subclass would take an instance of this container, and let it do all the work.This approach would allow a more flexible design of each error handler, and a clearer separation of responsibilities instead of all the
if/else
s we currently have chained together.Error handler interface
The interface of an error handler look something like this
Concrete error handler
This is just a reimplementation of the current check failure error handler we have in our
bot
repo.Error handlers' container
This class would register all error handlers, and allow to loop overthem to look for the handler that would fit.
We could register handlers under specific names if we ever want to have some "overriding" of error handlers in client apps.
Usage inside a cog
Once all the handlers are implemented, the error handler cog would be simplified to the following.
Things that can be added on top of the previous
The text was updated successfully, but these errors were encountered: