Open ryantheleach opened 2 years ago
Throwing results in the following log:
[22:43:47 INFO]: [Paper-Test-Plugin-thrower] Enabling Paper-Test-Plugin-thrower v1.0.0-SNAPSHOT
[22:43:47 ERROR]: Error occurred while enabling Paper-Test-Plugin-thrower v1.0.0-SNAPSHOT (Is it up to date?)
java.lang.RuntimeException: Succeeded to fail
at io.papermc.paper.testplugin.TestPluginThrower.onEnable(TestPluginThrower.java:18) ~[test-plugin-1.0.0-SNAPSHOT.jar:?]
at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:264) ~[paper-api-1.18.1-R0.1-SNAPSHOT.jar:?]
at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:370) ~[paper-api-1.18.1-R0.1-SNAPSHOT.jar:?]
at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:500) ~[paper-api-1.18.1-R0.1-SNAPSHOT.jar:?]
at org.bukkit.craftbukkit.CraftServer.enablePlugin(CraftServer.java:564) ~[main/:?]
at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:478) ~[main/:?]
at net.minecraft.server.dedicated.DedicatedServer.initServer(DedicatedServer.java:286) ~[main/:?]
at net.minecraft.server.MinecraftServer.runServer(MinecraftServer.java:1202) ~[main/:?]
at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java:317) ~[main/:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
[22:43:47 INFO]: [Paper-Test-Plugin-thrower] Disabling Paper-Test-Plugin-thrower v1.0.0-SNAPSHOT
[22:43:47 INFO]: [Paper-Test-Plugin-watcher] Paper-Test-Plugin-thrower::PluginDisableEvent
[22:43:47 INFO]: [Paper-Test-Plugin-stopper] Enabling Paper-Test-Plugin-stopper v1.0.0-SNAPSHOT
[22:43:47 INFO]: [Paper-Test-Plugin-stopper] Disabling Paper-Test-Plugin-stopper v1.0.0-SNAPSHOT
[22:43:47 INFO]: [Paper-Test-Plugin-watcher] Paper-Test-Plugin-stopper::PluginDisableEvent
[22:43:47 INFO]: [Paper-Test-Plugin-watcher] Paper-Test-Plugin-stopper::PluginEnableEvent
Results in a PluginDisableEvent without a corresponding Enable event.
This violates the principal of least surprise, but I could understand that being intentional if documented.
Well, this is likely derived from upstream behavior; I guess we could not call the enable event if the plugin disables and the disable event if the enable hasn't fired, but that creates a good chunk of eer here, but, I don't think that there is a great solution here which doesn't potentially introduce some risks, so am not sure how strong the argument here is to break from upstream
I havn't tested upstream yet, it may be better PR'd to them.
This violates the principal of least surprise, but I could understand that being intentional if documented.
Not to say this behavior shouldn't probably be looked at, but this does not violate the principle of least surprise.
Expected behavior
I expect to see the events for PluginEnableEvent and PluginDisableEvent reflect the reality of the situation, in that the plugin failed during enablement.
Either the enable event should not be thrown if the event failed to initialize, or the events called in the correct order.
Observed/Actual behavior
Note that enable and disable logging lines are in the correct order, but the event is not.
Note that the status of the stopper is correctly disabled at server load time.
Steps/models to reproduce
Watcher: (Note: Stopper should probably depend on Watcher)
Stopper:
Plugin and Datapack List
Just the 2 listed above.
Paper version
Latest, at time of writing:
Other
No response