One of the reasons I raised this point is that, today, modules are wildly
inconsistent about fataling.  If the nssock module fails to load or to
listen, the server continues, ever hopeful; if the nscp module fails, on
the other hand, it's going down and it's not going alone!  Between the two,
 I can generally tolerate a failure to load nscp far better than a failure
in nssock, but there's no mechanism for handling this sort of thing.

I suppose I'd like some kind of module load exception handler, the default
for which shuts down the server.

As for database drivers, I think it's never acceptable for a driver to
fatal because of a failed connection -- there's already a well-established
mechanism to report and detect connection failures at the time of a "ns_db
gethandle", and if that fails, you can exit yourself; if you want to make
sure you can connect to the DB at startup, do a gethandle and exit if it
fails; no reason to have the module issue the fatal, especially because
there may be cleanup required before the process terminates.

Reply via email to