[Feature] Solution to "SignGUI does not support the server version"

[keehl254]

Is your feature request related to a problem?

I absolutely love SignGUI as it allows me to provide users a clean interface for short-form text. It is also easy to work with. That said, the SignGUI class throws an exception in the static initializer block if the API does not support the current server version. Due to throwing in a static initializer block, the java runtime throws a "ExceptionInInitializerError," which cannot be caught. 

I would love to make it so that if the current version of signGUI does not support the version, my plugin could then move onto a backup Chat system. This is not currently possible. Instead, since I call SignGUI from an inventory click, the SignGUI errors without being caught and allows players to take the item that was clicked on. Depending on the scenario in which SignGUI is used, this could open up dupes or other problems for plugins utilizing this API.

What solution would you like?

Move the contents of the static block to a private, static method called "getWrapperIfSupportedVersion". This method would return the wrapper (or null if unsupported version). Set the static final WRAPPER variable to be the result of calling said method. This should allow you to initialize it to either null or the correct VersionWrapper depending on if the version is supported.

In the SignGUI.builder() method, check if WRAPPER is null. If so, throw a SignGUIException with the "unsupported server version" message. No other methods should need to be changed.

This should make it so we can catch the SignGUIException and perform an alternative solution (or simply message that the feature is unavailable right now). I know it sucks having to mark SignGUI.builder() with a throws declaration, but the alternative is not being able to catch this issue and plugins using it being broken while awaiting an update. This solution also doesn't require any change on the part of dev's implementing SignGUI since, despite what your IDE will yell at you, catching exceptions from a method with a throws declaration is optional.

Describe alternatives you've considered

I have considered copying and pasting the code straight from de/rapha149/signgui/SignGUI.java's static block to create my own class that does nothing but check if SignGUI is valid. I just figured this would be a shoddy solution, especially if the contents of that static block were to change in future releases of the API.

Any additional comments?

I may have overlooked an easier solution to checking if the version is not supported. I apologize if I had.

[Rapha149]

That's certainly a good idea, I never thought about the implications of throwing the exception inside the static block.
Regarding the exception, wouldn't it be easier to just use a RuntimeException instead? That way you could catch and handle it if you wanted to, but you don't have to, and your IDE won't show you an error. Or would that be some kind of bad practice?

Anyway, I will probably be able to add this tomorrow.

[keehl254]

I would consider it a bad practice, but not that bad. Usually, runtime exceptions would be used to state there is a problem with code. For example if someone calls your method incorrectly but there was no particular exception or error.

It certainly is smart in that using RuntimeException won't display an error for IDE's; that said, you may want to include in your "usage" area on the readme that it can throw an error if the version is not supported.

[Rapha149]

Ok, yeah, I can understand the reasoning that this is a bad practice. However, I tested your assertion that you don't have to catch a declared exception and in my case the compiler throws an error if I don't catch it. Despite this, I think throwing a non-runtime exception in SignGUI#builder might be the best idea. I'll just explain in the release notes that devs now need to catch it.

[keehl254]

My apologies for the poor explanation. Any new revisions to a plugin using SignGUI will need to catch it, otherwise the compiler will error. That said, if a plugin that used old SignGUI prior to this received no updates and tried to call the method in the new SignGUI class (somehow), the runtime would still allow it still despite there being no catch.

Since this API is offered solely as an addition and not it's own plugin, this will probably never happen. The only way I can think of it happening is if two plugins use different versions and neither remap the classes. It wasn't worth mentioning, and I apologize.

I think a non-runtime error would be perfect. I know it's unfortunate needing to account for throws, since try catches are somewhat ugly, but it opens up a lot of possibilities.

[Rapha149]

Ah now I understand what you meant 😅
I'll implement the feature now, it shouldn't take too long since it's not that much to change.

[Rapha149]

The new version is released and should be available on Maven Central in a few hours. Thank you for requesting this, I wouldn't have thought of it otherwise.