Logger failure should not impact the calling process

[andyhardy]

Currently, if a failure occurs within logger the exception is propagated back to the calling routine causing that routine to also fail - this should not happen.

Example: the logger fails to insert into the log tables due to table space issues, the exception is raised to the calling process which in turn fails.

As a quick hack, I've added exception blocks to those procedures that perform inserts but some thought might be wanted on how to address more general failures and how to report them.

[SvenWeller]

I strongly disagree. Errors in the logging framework itself should also be propagated though the error stack.

[barsema]

I agree with Sven, Besides I would not call adding exception blocks around logging calls a "hack" if you truly don't care wether the logging completes or not.

[andyhardy]

Sven, does this mean that you are happy to put exception blocks around every 'debug' statement in your application in case the logger fails? If so, then I agree that the code should remain as-is.

[jeffreykemp]

Sven didn't say that - he said to allow exceptions to propagate through the error stack. You need to put monitoring in so that tablespace issues are detected before they become a problem.

If a fire causes your smoke alarm to sound, you don't remove the batteries and go back to bed.

[andyhardy]

OK!

I don't see logger as a smoke alarm, more of a bell that rings when someone flushes the toilet. If the bell fails because the battery is flat, I still need the toilet to flush!

To me, logger is a utility primarily used during debugging - it's not a core part of the application that I'm building.

[barsema]

The exceptions are the fire alarm not logger.

If you are not 'debugging' Logger will not log anything and therefore not fail.

If you are debugging I would expect you care that it actually does log if you ask it to.

Logger can only fail if you ask it to do stuff, if you ask it to do stuff and it can't it should report that. simple as that.

[andyhardy]

Maybe, but I don't expect the production system to fail overnight because someone turned on debugging and wasn't around to check that the table space was OK six hours later. If they get back into the office in the morning and there's no logging, they might notice that it's because the table was full.

[jeffreykemp]

If someone turned on debugging in prod and then the server starts failing with tablespace errors, your monitoring solution is either not working properly or nonexistent, and that's a problem.

Also, it would probably be a good idea to avoid turning logging on "full" permanently in a production system. Instead, use the session-based logging with an automatic expiry time.

Pointing the finger at Logger for these procedural issues, and trying to work around them instead of solving the root issue, is not in your best interest.

[barsema]

I can understand you would have liked logger to fail silently in this particular instance, however in any other scenario software failing silently is a major paint to diagnose.

[SvenWeller]

First of all I use logger primarily to log ERRORS. Sometimes for tracing. For real debugging there are better tools. I never ever want that logger silently "forgets" to store the errors that happened.

[SvenWeller]

@andyhardy How about if you simply write a wrapper around the logger.debug call, where you handle the error. Nobody prevents you from doing this. You would still run into the tablesapce issue when logging an error. but not when logging a debug message.