serenity
serenity copied to clipboard
Adopt an Error handling method similar to Actix
Inside Actix you can implement ResponseError on your Error and Actix will call this method if an Error occurs. https://actix.rs/docs/errors/
My example trait would be
pub trait CommandError {
async fn handle_error(context: &Context, message: &Message);
}
pub trait EventError {
/// The event type would need to be changed
async fn handle_error(context: &Context, event: &Event);
}
Inside these traits I would be able to call maybe reply to message "An Internal Error Has Occurred" And I also have an Error Logging Channel on this server to where I send the actual error so I can debug the problem.
What do you do if an error occurs in these methods? Honestly, I do not really know. This only would be an issue if the Error was like an connection to Discord error or bad code. The first one being handled by logging in the console for the admin to figure out later.
P.S both traits would need a reference to &self
Is this referring to errors in standard_framework commands, or errors in EventHandler functions?
Is this referring to errors in standard_framework commands, or errors in EventHandler functions?
I haven't touched Serenity in over a year now.
But both. You should be able to define your own Error type and return it on commands and events.
Alright. Custom error types in standard_framework commands is not going to happen, because development effectively stopped and its successor already supports custom error types and a central on_error callback.
But custom errors in EventHandler could theoretically be implemented, at the cost of breaking all existing usages of EventHandler.
I feel like it's not worth it, because I think the future of handling arbitrary events is not EventHandler but a central callback with a FullEvent parameter, like in poise. By centralizing the callback, passing auxiliary data or handling errors in a centralized way becomes much easier
Alright. Custom error types in standard_framework commands is not going to happen, because development effectively stopped and its successor already supports custom error types and a central on_error callback.
Ok cool. I did not know that. As I mentioned I haven't played with Serenity in awhile.
But custom errors in EventHandler could theoretically be implemented, at the cost of breaking all existing usages of EventHandler.
I feel like it's not worth it, because I think the future of handling arbitrary events is not EventHandler but a central callback with a
FullEventparameter, like in poise. By centralizing the callback, passing auxiliary data or handling errors in a centralized way becomes much easier
Ok sounds good
We have deprecated the standard framework and are moving towards poise being the go-to framework instead.