Hi!
In development, I’m seeing that when an exception is thrown on the server…I cannot access the app through the client until I restart Meteor in my terminal. This can take some time. Is this supposed to happen? On Prod, would this then require a manual Server restart? Thanks!
Can you please show us the exception thrown on the server?
The server should be restarting when you edit the file. Sharing your specific error may help.
Experienced this quite a number of times and it might be related. For us, these were unhandled rejection errors and these errors vary.
Our solution is to universally catch unhandled rejection errors. This helped us in logging the error and not causing the server to become unresponsive.
I ran into this (mis?)conception once or twice too, either myself or somebody asking me this, which always tripped me up.
I think we may have to differentiate two things:
There is a category of errors we might call a build error. A syntax error for example, or a missing module or something else configured incorrectly (maybe something in the settings, wrong environment vars etc) which prevents the server from starting up, halting the startup process and waiting for you to fix it so the app can be built and ran.
There are runtime errors, where there’s a programming error maybe accessing an invalid object field for example, or something else failing, maybe access to an external resource (network errors). This second category we can call “runtime errors” because they occur once the app has started and runs correctly.
There are other, “harder” errors during runtime, such as certain exceptions from the node runtime itself, eg. out-of-memory errors or other “unfixable” errors which can occur at runtime, where it’s probably not possible or not considered safe for the system to carry on on its own. A properly configured node environment should then restart the container / app in the hope that it’ll run at least for a certain time until the next exception occurs & send a mail or a warning to someone to fix whatever happens (and maybe do other stuff to mitigate the issue, but let’s stick with this for now).
Normally it is expected that the developer fixes the build-time bugs while developing and doesn’t ship a broken version to the server. These versions will never start and the clients can’t reach those, because they actually never started.
On deployment, it’s also possible that an error occurs while building the app (if you build it again there, depends on your setup / pipeline), it could be that there’s a different system architecture in play for example or that there is a different environment (node, database etc) which leads to these issues. Also it might be configured differently which could lead to errors. Different network conditions etc.
So you should monitor your service on deployment to check whether it has started correctly. Most automated services (I 
scalingo.com ) check the built version and wait until they have started up, eg. there is no repeated text output on the console (which could indicate problems) and until the app answers on the default port. Only if the “life signs” seem ok the existing app container will be replaced with the freshly built one.
From there on you should be mostly ok. The application will have started and we can carry on to the next phase of the applications lifecycle, happily chugging and serving stuff in either dev or production.
Once the app has been built and started successfully, regular runtime errors shouldn’t lead to service interruptions. They should be logged to the console probably and the logs should maybe be reviewed regularly.
There are all kinds of things you can do with these errors, there are client side errors in web apps too of course. There are many services to aggregate & analyze these errors.
But they normally shouldn’t end your app.
If they do something is configured / set up incorrectly somewhere. Node (and thusly meteor-) Apps should run stable for weeks and months and years in the best case.
As I said above, there is a class of “tougher” runtime errors where which might lead to a server failure, but that should be monitored by the environment running the application & then handled by restarting the server and alarming the crew.
That’s my few cents.
I think this confusion might spring from this difference, that while in development mode an error prevents the app from running and it needs fixing until it works again.
In deployment / once the app is running, run time errors shouldn’t take the app down, basically.
This is my current understanding of the world, if there is more to know / if I don’t know the right things, I’m happy to learn more!
Have a great one everyone, gotta start working now! 
Wow. Amazing response.
Thanks 
Did it actually help?