Feature Proposal: A soft-failure-mode for ASSERTs

Motivation

Sometimes problems manifest on a production server, and it is hard to reproduce them on a dev server. It would be really handy to have access to the debug information from the ASSERTs without killing the server.

Description and Documentation

1. Provide a way to enable the soft failure mode, e.g. by setting FOSWIKI_ASSERTS to "soft"
2. Change ASSERT in Assert.pm to use Carp::cluck instead of Carp::confess when in "soft failure mode"
3. Update the unit-test runner to take into account the new possible status for ASSERTs, where it prints out if ASSERTs are enabled or not

Here is a possible specification for FOSWIKI_ASSERTS:

FOSWIKI_ASSERTS value	Behaviour	Comments
not defined	ASSERT is disabled	existing behaviour
0
any other false value
soft	ASSERT emits warnings to debug log but does not die	New proposed behaviour
1	ASSERT dies	existing behaviour
any other true value

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: MichaelTempest - 14 May 2010

Discussion

Michael pointed out cluck to me on IRC the other day, and it worked very well in getting some debug information on a live server. This sounds like a very good suggestion. We could probably have it enabled by default for the Release Candidate builds, to improve the odds of catching issues. It would also let us be more aggressive with adding asserts into the code.

-- GeorgeClark - 14 May 2010

yes please - but lets do it like Monitor - where admins can register a module, or method to turn ASSERTs on for

(we should really place these into the LocalLib.cfg)

use Monitor ();
Monitor::MonitorMethod('Foswiki::Users');

or a function

use Monitor ();
Monitor::MonitorMethod('Foswiki::Users', 'getCanonicalUserID');

If we can find a way to make the ASSERT's external to the function code - ala Pod::Snippets (or other evil magic) we could even make it fast as.

changed proposal to output to the 'debug log' we really need to insist on that abstraction - some day soon we'll need syslog, db, nosql style loggers - hitting my disk for each request is just another straw.

-- SvenDowideit - 14 May 2010

Yes - "debug log" is way better than "STDERR"

I agree with George that it would be useful if the 1.1 release candidates shipped with (perhaps a very limited form of) soft-failures for asserts (even if disabled by default). I agree with Sven that more control is better. Therefore, I suggest we aim to define the control interface now, even if that control interface is only (fully) implemented in 2.0.

1.1 is under feature freeze and yet here I am proposing a (small) change to 1.1. Kenneth - what do you say?

-- MichaelTempest - 15 May 2010

Sorry for late response.

This does not change the operation for the end-user. It is a debug feature to enable more stable code. I cannot see a problem with that from a feature perspective.

As long as this can be disabled easily and completely in normal mode (which should be default) I have no worries. Something that helps getting code more stable should be a good thing as long as it is not too much code rewriting.

-- KennethLavrsen - 07 Jun 2010