Communicate errors with Exceptions where appropriate

[dmitry-timofeev]

Currently some operations in PluginManager may not complete successfully, according to documentation:

• PluginManager#loadPlugin — returns null if failed to load the plugin
• PluginManager#unloadPlugin — returns false if failed to unload the plugin

Such return values

• Are quite easy to miss to check (and get an error down the road).
• Do not communicate why the PluginManager failed to perform the requested operation.

The list is not exhaustive, and currently includes only the operations I bumped into. There might be some other operations that might benefit from more direct and detailed error reporting.

See also

• Mailing list discussion

[decebals]

I added throws PluginException in the signature of PluginManager#loadPlugin method.
I think that for PluginManager#unloadPlugin is not necessary.

From mailing list discussion:

Other discussion is what kind of exception we prefer: checked or unchecked (runtime) exception. Is it a good to create a PluginRuntimeException? For example PluginManager#loadPlugin will throw PluginException or PluginRuntimeException?

In the end I opted for a checked exception.

[dmitry-timofeev]

Thank you, it makes sense — the clients that explicitly load plugins are likely to need to recover when a plugin turns un-loadable. Regarding unloadPlugin — can this operation really fail?

[decebals]

Now I think this feature is fully implemented.