Event processing stops when processQueue throws

[NicolaVerbeeck]

When processQueue throws an exception, the entire event bus stops working (mProcessing remains true)

Suggest adding a try - finnaly block that resets mProcessing

[sergejsha]

This was intentional design decision. Bus fails fast to reveal all errors immediately during development. If exception happens, then it must be fixed. Application will typically force close afterwards.

Why would you need to resume and continue? What is your exact use case?

[NicolaVerbeeck]

I agree that this helps fix application errors by forcing this during development, but when an error like this would occur in a production app, in theory, the app could continue working (if the exception was caught, in which case the app design should have been better, agreed).

I think this is a balance between forcing better flow design and robustness in case of failure. Now that we know runtime errors can be thrown when registering for example, we can check for this (and remove the catch-all from otto shame)

[sergejsha]

I believe your request is good. I just wanted to better understand all consequences.

Current implementation starts to simply ignore requests coming after an exception. This is rather hiding issue, then making it obvious, which is bad. A better solution would be either to continue to handle events properly, or to fail on every follow-up request showing that bus state is invalid. As far as Bus does not hide any exceptions and if subscribers caught them, the bus must recover and continue with prop event dispatching. It won't make things better, and would be robust.

[sergejsha]

Changes have been pushed to the master branch