Print reason for service initialization failure

[bennostein]

Would have saved me some headache earlier... without this, errors during service initialization are silently dropped and the process exits 0 without ever spinning up servers.

[skiplabsdaniel]

I don't understand why you say that the exception is silented, if the init fails, the server doesn't start and the message is displayed, the only reason I can see for the message to be ignored is that there is no await on the runService.
And if the message doesn't appear in a certain environment, it's better to use try catch on runService to handle all cases.

[bennostein]

In the example I'm working with (running the hackernews example containers under kubernetes) all of the runService calls are awaited, but no message is printed without this patch. I'll see if I can catch on runService instead of making this change, but I don't understand why that's "better" -- it seems to me that printing no matter what is better than requiring user code to catch/print explicitly.

EDIT:
Indeed the message can be printed with

await runService(...).catch(console.error);

I suppose the silent failure is due to the handling of stderr/stdout in the WASM environment.

[bennostein]

So I suppose I'd propose either (A) making this change or (B) going through all of our examples and docs and adding .catch(console.error) on each runService call, so that people who copy/paste that get error messages. Either way's fine by me.

[skiplabsdaniel]

Indeed, it's a matter of taste, it can be done like that.