Lack of interest Per-addon exception handling

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Robust

Well-known member
Can we assign an add-on to exceptions?

Ideally, this would make it possible to use something for exception handling (something like Sentry) in public add-ons and report such exceptions automatically to the developers for faster bug fixes and give us the data we need for a quick fix.

I feel like it's a fairly minor feature, so I'd love to see something like this for XF2's full release if possible and support for things like Sentry, optionally, would be great.
 
Last edited:
Upvote 1
This suggestion has been closed. Votes are no longer accepted.
I think you'd just need to create your own exception class that you'd use
Most exceptions aren't thrown manually by the add-on itself. It's a bit easier if XF assign exceptions to the add-on that caused them, and you can add a hook I'm guessing (in some class, somewhere, or create a code event for it) that would be able to perform additional actions for exceptions with a certain add-on.
 
How would XF know what add-on caused the exception? Just because the last class in the stack trace is Foo\Bar\Pub\Controller\XYZ doesn't actually mean that add-on caused the error. Not to mention that if there is an exception that kills the whole site chances are your listener wouldn't fire anyways
 
How would XF know what add-on caused the exception? Just because the last class in the stack trace is Foo\Bar\Pub\Controller\XYZ doesn't actually mean that add-on caused the error. Not to mention that if there is an exception that kills the whole site chances are your listener wouldn't fire anyways
Not sure off the top of my head. I can think of a few silly designs but there's probably a better way to do it. It's not something I've done before so I wouldn't know the best method.

Nothing is impossible though and I doubt this is *too* unreasonable to implement. Perhaps by XF 2.1 at least. It'd be extremely useful to add-on developers. Customers complain about bugs but sometimes it's just not worth creating tickets all the time to report them, or not enough information is provided by a customer when they do report one. This, at least, ensures that bugs can be tracked centrally in something like Sentry and can be processed from there.
 
How would XF know what add-on caused the exception? Just because the last class in the stack trace is Foo\Bar\Pub\Controller\XYZ doesn't actually mean that add-on caused the error. Not to mention that if there is an exception that kills the whole site chances are your listener wouldn't fire anyways
I'm just thinking out loud here, but what about if each addon's class extensions had its own (optional) assigned exception handler? It could (theoretically) be toggled in addon.json, it would be the class path such as DBTech/Security/XF/Exception/Handler (or whatever).

Although as I'm typing this, maybe XF doesn't have enough control over the code to automatically add the overridden exception handler to the start & finish of each function...

In either case, I can see a lot of uses for this. It would let us create an optional feature in our mods to automatically submit exceptions, or a button in the server error log for transmitting exceptions to a developer-specified endpoint.

Actually, maybe that is a more reasonable suggestion? If XF was able to detect which addon ran a specific function at a specific time, via an overridden exception handler or some other means, the exception could have an addon_id column in the error log table.

We could then specify a class in addon.json for handling exceptions, and give users a button in the server error log that would invoke this class and flag it as "reported".

I'm gonna do some research into XFCP and see if this is feasible at all, I made myself excited now :D


Fillip
 
Top Bottom