Discussion: should all callbacks be wrapped so that exceptions are caught

I personally strongly believe that all callbacks should be wrapped in try-catch blocks so that even if these 3rd party code sections throw exceptions, the rest of the code continues as normal. This way we don’t have to worry about IF code being interrupted, left in an intermediate, broken state. The plugin’s name and if possible, some sort of gui identifier (eg. the associated class’s simple name) should be included the error messages that the catch blocks produce.

Sometimes the best way to achieve this wrapping/boxing is to not expose a getter to the callback, but a method that calls the callback instead. This breaks all logic that relies on the getters, the real question is whether anything at all relies on it. Eg. GuiItem#getAction() returns a non-null value (it internally creates an empty lambda), in that case relying on the return value is very hard and probably no one does it. It might be possible in connection with nullable getters though.

List of what would be affected: (hopefully this is a complete list)

• GuiItem#getAction()
• Pane#onClick (protected variable)
• Gui#getOnClose()
• Gui#getOnOutsideClick()
• Gui#getOnGlobalClick()
• Gui#getOnBottomClick()
• Gui#getOnTopClick()

I would be more than happy to implement and PR this, the question is whether I should. This is a place for arguments and counter-arguments.

[stefvanschie]

Let’s keep this open for a little longer - if no one uses the current methods, they can go; if people are using them (and want to continue using those instead of the new callX versions) we can just keep them.

[stefvanschie]

I’ve gone through the dependents of this framework and from what I can find, none of them seem to be making use of the getX methods, so replacing them with their equivalent callX method should be fine.