This is the kind of inconsistency I am working to fix, across all of the modules. Not sure adding a default handler is the right way to go; the 80% case is for a straight failure. nssock, in my opinion, should fail if it can't bind to a port. Adding a default handler will add some complexity that is probably not necessary, but I'm certainly not an expert in this area of AOLserver yet.
/s. > -----Original Message----- > From: AOLserver Discussion > [mailto:AOLSERVER@;LISTSERV.AOL.COM] On Behalf Of Peter M. Jansson > Sent: Friday, October 18, 2002 1:23 PM > To: [EMAIL PROTECTED] > Subject: Re: [AOLSERVER] Module arrogance > > > 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. > >
