I moved the usage of errors.logErrorAndExit to ./core/index.js` directly as that is the entry point of the ghost application and should be the same place that handles if ghost should quit.

I also rejected the promise there for consistency's sake even though it never gets hit due to the process quitting.

Sooo I finally got around to testing this :) I'm excited about this change and what it could do for our tests.

However, I believe there is still a little bit of refactoring work needed in server/index.js:

The function startGhost (which does nothing more than provide nice messaging to the user) is the callback for app.listen which is async, this isn't taken into account, so we resolve the promise before the server is actually up and running.

I'm wondering if we can wrap app.listen in nodeFn to promise-ify it, and make this, and the startGhost messaging part of the promise chain.

I also noticed that throwing a random error during the chain did not result in .otherwise being called, and I'm wondering if there is further tweaking needed to ensure errors are properly handled.

Whilst I'm here looking at this file, I also think it could do with some serious love - it's a higgledy-piggledy collection of stuff at the moment. I wonder if we can make the promise chain clearer somehow? I'm adding this here because @hswolff you have been the king of the general app structure refactoring and may have ideas, but it's obviously not actually part of this PR - more like part of #2182.

Updated the PR to fix the issue where startGhost was called after the promise for the startup flow was resolved. I tried using nodeFn w/ app.listen however kept getting obscure errors of listener must be a function. Went with another plain ol' deferred object instead.

Where did you throw errors that resulted in improper handling?

I can approach some clean-up as a follow-on to this PR for sure. I can apply it in pursuit of #2182.

I just threw an error in the last async block here: https://github.com/hswolff/Ghost/blob/d7ac4d44325641b11b7ab480f1307c3cbafeef2a/core/server/index.js#L213

Aha...so reason for that is https://github.com/hswolff/Ghost/blob/ghost-startup/core/index.js#L24 - we have our own specific error handling.

Either we can pull our specific handling to end the process or just expose the error to the user to handle with as they please.

It seems to me that if I get a success through the promise I should be able to get the failure that way too? It's not doing anything terrible right now just not consistent.

What do you think?

I think it'd be best to keep consistent and allowed to be managed by user land.

Keep getting this random errors that occur occasionally.

 1) Frontend Routing Home should respond with html:
     Error: expected 200 "OK", got 500 "Internal Server Error"

It's not consistent though.

@hswolff the build error is a timing problem where grunt-express-server is not waiting for Ghost to fully shut down. I tried to fix it some time ago, but gut distracted. I'll have a look.

Ok so this is now working perfectly in the module context, but in normal Ghost context, it just hangs.

(I am adding throw new Error('I ARE ERROR'); to ~line 238 of server/index.js)

Can we reconcile the two so that both work as expected i.e. there is an error message?

Update I think all that is needed is to call logErrorAndExit in the main ghost index file?