Closed baltpeter closed 11 months ago
Why are we not awaiting it, though? The process exits after the app has been started.
To be symmetric with objection. We could change it for the monkey command, but then we'd have to implement something for objection anyway. (Unless the result from https://github.com/tweaselORG/meta/issues/16 is that we want to switch to something else).
I don’t know how this would look like. We can not expect a try {} catch {}
to catch errors asynchronously in the main thread. What we can do is not reject in execa. But this way, errors might not stop the execution, which we might want. These errors can only be handled unsynchronously.
We could try to use a cancellation token or something similar, but this is harder than it looks. We cannot do much in appstraction, this has to happen mostly in the implementation code. Though we could return an AbortController
in startApp
.
Let's wait for a decision of whether we'll continue using objection in the first place before we put more work into this. I just wanted to note it.
I noticed this with
com.anysoftkeyboard.languagepack.german
in https://github.com/tweaselORG/meta/issues/16. The app is just a keyboard with no main activity that could be started, which is whystartApp()
fails:So far, so expected. However, my
startApp()
call is in atry
-catch
and the error wasn't caught. I'm assuming that's because we're instantiating theexeca
promise but not awaiting it.