Handler convenience debug methods #22

New Issue

delvh · 2021-09-24T20:44:32+02:00

delvh commented

2021-09-24 20:44:32 +02:00

Add a method that simply lists all handlers in the order in which they would be executed when you have a specific input event, without actually invoking them, i.e. using

String.format("event handler '%s' with priority %d", eventHandler.handler.toString(), eventHandler.priority);

At best, a second method should be added as well that simply counts how many handlers would be called.
That would help with debugging as seeing what is going on inside event-bus is tedious even with a debugger.

Add a method that simply lists all handlers in the order in which they would be executed when you have a specific input event, without actually invoking them, i.e. using ```java String.format("event handler '%s' with priority %d", eventHandler.handler.toString(), eventHandler.priority); ``` At best, a second method should be added as well that simply counts how many handlers would be called. That would help with debugging as seeing what is going on inside event-bus is tedious even with a debugger.

delvh added the

1

enhancement

could have

labels 2021-09-24 20:44:32 +02:00

kske commented

2021-09-24 21:47:08 +02:00

Are you interested in a list of strings, or rather the actual event handler objects? Right now, the EventHandler class is internal and not exposed outside the module.

By changing that, we could allow a more direct interaction with the handler configuration, including an ordered list of the handlers to be called for an event (essentially making EventBus#getHandlersFor public.

Are you interested in a list of strings, or rather the actual event handler objects? Right now, the `EventHandler` class is internal and not exposed outside the module. By changing that, we could allow a more direct interaction with the handler configuration, including an ordered list of the handlers to be called for an event (essentially making `EventBus#getHandlersFor` public.

kske self-assigned this 2021-09-24 21:47:16 +02:00

delvh commented

2021-09-24 22:41:24 +02:00

List of strings, especially if the handlers implement toString correctly.
Or do you currently store java.lang.reflect.Methods inside the handler? Because if that is the case, there surely is a nice way to get the name of the method that is registered as event handler to print out for debugging purposes.
As this is intended to be a function to help with debugging, I only want to see which methods and/ or objects are registered for a specific event and when in the event dispatching lifecycle they are called.

Making this method public does not seem to be a bad idea to me. That would cover at least the second use case I mentioned directly (number of event handlers for a specific event).
Furthermore, I think the convenience method returning a list of strings can be declared as well as it encourages the default query for debugging purposes instead of having to tediously declare it yourself when debugging.
Adding new functions yourself whenever you need to debug something is in my opinion inefficient as those functions will always be deleted afterwards.

List of strings, especially if the handlers implement `toString` correctly. Or do you currently store `java.lang.reflect.Method`s inside the handler? Because if that is the case, there surely is a nice way to get the name of the method that is registered as event handler to print out for debugging purposes. As this is intended to be a function to help with debugging, I only want to see which methods and/ or objects are registered for a specific event and when in the event dispatching lifecycle they are called. Making this method public does not seem to be a bad idea to me. That would cover at least the second use case I mentioned directly (number of event handlers for a specific event). Furthermore, I think the convenience method returning a list of strings can be declared as well as it encourages the default query for debugging purposes instead of having to tediously declare it yourself when debugging. Adding new functions yourself whenever you need to debug something is in my opinion inefficient as those functions will always be deleted afterwards.

kske added

8

and removed

1

labels 2021-11-01 09:31:06 +01:00

kske commented

2021-11-01 21:01:51 +01:00

Currently, the toString method of EventHandler has the form EventHandler[method=%s, eventType=%s, useParameter=%b, polymorphic=%b, priority=%d], which contains all information that makes up the handler in human-readable form.

As the standard output is not always accessible depending on the code base in question, I would rather prefer to return a string instead, made up of such handler descriptions in the correct order, separated by line breaks. At the top, a line in the form of "Handler execution order for event type X (n handler(s)):" could be included.

Currently, the `toString` method of `EventHandler` has the form `EventHandler[method=%s, eventType=%s, useParameter=%b, polymorphic=%b, priority=%d]`, which contains all information that makes up the handler in human-readable form. As the standard output is not always accessible depending on the code base in question, I would rather prefer to return a string instead, made up of such handler descriptions in the correct order, separated by line breaks. At the top, a line in the form of "Handler execution order for event type X (n handler(s)):" could be included.

👍 1

kske referenced a pull request that will close this issue

2021-11-01 21:49:39 +01:00

Handler Execution Order Debugging #25

kske closed this issue

2021-11-02 09:03:10 +01:00

Sign in to join this conversation.