I agree with Jim's position. If the module isn't working or can't get what it needs to run, a hard failure will force you to work out the problem instead of assuming that all the parts were working fine. If the server continued to roll, you'd really have to test all your modules (by connecting to the SSL port, for example) every time you started your server after any change to ensure things really were still working.
/s. > -----Original Message----- > From: AOLserver Discussion > [mailto:AOLSERVER@;LISTSERV.AOL.COM] On Behalf Of Jim Wilcoxson > Sent: Friday, October 18, 2002 11:30 AM > To: [EMAIL PROTECTED] > Subject: Re: [AOLSERVER] Module arrogance > > > Personally, I like hard failures. > > If I configure a database in my nsd.tcl, it seems obvious > that I want a database. If the server starts anyway without > one, then instead of having an immediate, obvious error to > handle, I have a subtle one. I go to my home page, and the > page comes back, so I assume the server is working. But 3 > hours later, someone goes to a page that needs to use the > database, and it dies. > > It'd be fine to have a config setting that says "keep going > if you can", maybe even with multiple values to say how > severe an error can be before causing a shutdown. In fact, I > think there already is something like that, or used to be. I > wouldn't turn it on for critical errors like not being able > to contact a database. Just my personal preference in > handling important errors. > > An important distinction to me is whether a module decides "I > can never work", or "I can't do what someone wants for this > request or at this time". If a module is loaded and knows > that it can never work right because of circumstances that > aren't going to change, then I think it's appropriate for it > to bomb hard. > > Jim > www.rubylane.com > > > > > I think that modules should not issue fatal errors and > terminate the > > server unless the module determines that the error it has > encountered > > will absolutely prevent correct operation of any part of > the server. > > For example, the current nscp module will terminate the > server with a > > fatal error if it cannot listen to the specified control > port, but the > > server would be perfectly capable of processing HTTP requests > > (assuming nothing else went wrong), so I'd like to suggest that > > modules be more conservative in deciding when the server can't > > continue without them. Database drivers are another > example -- if the > > driver can't connect to the DB, there's an API to return > the failure, > > and with good engineering, you should be able to construct a server > > that does something reasonable even in the absence of a db > connection > > failure, so a fatal isn't a good idea. > > > > Anybody have any feelings one way or the other? > > > >
