Closed Sparky983 closed 1 year ago
TODO: figure out a way of handling exceptions
The issue is that from a Button.Subscriber
's perspective it would only make sense for it to be called if the action before it was successful. For example a Button.Subscriber
that syncs two items should only expect to be called if the action (the change to a Button
) actually happened. It also wouldn't help that a previous failure of a subscriber handling an event would cause subsequent subscribers to just be ignored.
On the other hand, from a caller's perspective, they wouldn't expect that the name had changed since the call failed (due to a subscriber failing to handle an event).
The first thing I thought of was to print failed Button.Subscriber
calls via Exception.printStackTrace()
, but the consumer may want to decide how failure is handled.
SubscriptionException
This solution would make name(Component)
, lore(Component...)
, etc. throw SubscriptionException
s (or similar) when a subscriber fails to handle an event. The issue with this is callers may not expect an exception to be thrown or not want to be responsible for handling the failure.
This solution would add a exception(Button.Subscriber, Exception)
(or similar) to Button.Subscriber
where any subscriber can choose how to handle exceptions thrown by other subscribers. The only thing that needs to be dealt with is if an exception(Button.Subscriber, Exception)
call fails and how that would be handled, whether the exception is simply swallowed, exception(Button.Subscriber, Exception)
is still called (and possibly cause stack overflow which is somewhat helpful), or to simply issue a warning (possibly via adventure's Nag
class).
failure event failure solution: print the exception
1/2 of #24