4

I'm trying to find the best place to handle connectivity errors, or any other global errors that crash the server.

What is the right place to catch adapter/global errors and not have them crash the server?

Specifically, I want to handle these types of errors in a graceful way:

Error spawning mySQL connection:
error: Hook failed to load: orm (Error: connect ECONNREFUSED)
error: Error encountered while loading Sails core!
error: Error: connect ECONNREFUSED
Madd0g
  • 3,841
  • 5
  • 37
  • 59
  • http://stackoverflow.com/questions/7310521/node-js-best-practice-exception-handling ? **tl;dr** use `try {} catch` – brandonscript Dec 19 '13 at 21:09
  • @r3mus - it's an error from sails though, I'm not sure how to even wrap it in my code, it can't connect to the db and can't start the ORM, I want to handle that gracefully – Madd0g Dec 19 '13 at 23:41
  • Oh, you'd have to find the actual file that Sails generated and add it in manually (I believe?) I'm really new to Sails ;) – brandonscript Dec 19 '13 at 23:46
  • This is why sails (and all monolithic frameworks for that matter) are a waste. You sacrifice convenience of typing a couple lines of code for control over your app. I tried using sails (and other frameworks like CakePHP and RoR that subscribe "Convention over Configuration") and gave up. I'd rather my hands cramp up then lose control over MY app. – srquinn Dec 20 '13 at 02:29

1 Answers1

3

from the sails docs: http://sailsjs.org/#!documentation/config.500

thats the error handling sails exposes from within the config

if your error passes that, you can hook in there, otherwise you can hook in node's process

process.on('uncaughtException', function (err) {
  if (err.toString() === 'Error spawning mySQL connection') {
    //rende some error page
  }
})

if the exception thrown is async the only way to catch it is trough process

do note however, that these kinds of errors are almost always unrecoverable, so crashing (and restarting) is the best approach

most modules loaded use local variables and expose only a subset of their internals trough module.exports, unloading a module and restarting its local code can be done, but you would need to unload all dependant modules and all modules holding references to it also. Thats why the normal approach is to let it crash

Paul Scheltema
  • 1,993
  • 15
  • 25
  • just let it crash? I'm not used to that, but ok :) – Madd0g Jan 02 '14 at 20:26
  • @Madd0g well if you can recover from an exception, then sure catch it. But if you cant recover theres no point in catching it either (maby log and serve a last-resort error page, but then restart) – Paul Scheltema Jan 02 '14 at 23:36