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?
>

Reply via email to