What is the idiomatic way to make a plugin that can fail to initialize?

[Kazuo256]

First time here, please tell me if I do anything wrong. Here's the question in more detail:

At what execution point should it fail? When we try to add the plugin? During the startup stages? Using some sort of bootstrap state?

How does the plugin notify the failure to the rest of the application? Is it OK to abort overall initialization? How can we do that without relying on AppExit, since it seems to only be checked at the end of the game loop?

Thanks in advance!

[lukors]

I'd say it's fine to just panic if your plugin fails to init. Do you have a concrete example?

[Kazuo256]

Yes, my specific use case is to make a crossterm plugin for my game that can (theoretically) fail, in which case I wanted the game to graciously enter a conventional prompt mode (while still running bevy).

[lukors]

As far as I know there is no "correct" way or time to fail or recover when initializing a Bevy plugin. Like in general programming, it depends on what you want to happen. :)

I'm not sure how to graciously shut down if an init fails. I can think of two ways: checking if the crossterm resource (assuming it exists in a resource) exists before any use, or having an "init" state. Both solutions add boilerplate though, so not ideal. Maybe it's possible to manually tell Bevy to check for AppExit?

You didn't ask for advice for your specific situation, and I don't know anything about crossterm, so this might be totally useless and/or obvious, but I'll give my thoughts anyway. :)

Maybe you can have two states: one that runs system(s) for the conventional prompt, and one that runs system(s) for the crossterm.

When initializing the plugin you can change to one state or the other depending on if the crossterm init succeeded.

If it matters to the plugin user if crossterm is being used, this can be exposed as an enum in a Resource or for instance.

[Kazuo256]

Thanks for the answer! I wanted to make sure I followed any conventions if there were any but, since there doesn't seem to be, I'll just do what seems best for my case. In particular, your suggestion:

Maybe you can have two states: one that runs system(s) for the conventional prompt, and one that runs system(s) for the crossterm.

When initializing the plugin you can change to one state or the other depending on if the crossterm init succeeded.

Sounds very good to me!

I really appreciate you taking the time to answer my question.