serenity icon indicating copy to clipboard operation
serenity copied to clipboard

Adopt an Error handling method similar to Actix

Open wyatt-herkamp opened this issue 3 years ago • 1 comments

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.

wyatt-herkamp avatar Dec 29 '21 16:12 wyatt-herkamp

P.S both traits would need a reference to &self

wyatt-herkamp avatar Dec 29 '21 16:12 wyatt-herkamp

Is this referring to errors in standard_framework commands, or errors in EventHandler functions?

kangalio avatar Apr 26 '23 07:04 kangalio

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.

wyatt-herkamp avatar Apr 28 '23 13:04 wyatt-herkamp

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

kangalio avatar Apr 28 '23 14:04 kangalio

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 FullEvent parameter, like in poise. By centralizing the callback, passing auxiliary data or handling errors in a centralized way becomes much easier

Ok sounds good

wyatt-herkamp avatar Apr 28 '23 14:04 wyatt-herkamp

We have deprecated the standard framework and are moving towards poise being the go-to framework instead.

arqunis avatar Jan 25 '24 19:01 arqunis