Re: How do you handle debug code? Removing from production versus conditional execution

From	Martin Gregorie <martin@mydomain.invalid>
Newsgroups	comp.lang.php
Subject	Re: How do you handle debug code? Removing from production versus conditional execution
Date	2019-05-03 08:18 +0000
Organization	albasani.net
Message-ID	<qagtgf$oje$1@news.albasani.net> (permalink)
References	<a2740b73-91c2-4002-9573-d0204fe2bec7@googlegroups.com>

Show all headers | View raw

On Thu, 02 May 2019 18:00:22 -0700, Ryan wrote:

> Perhaps an age old question, but how do you all deal with your debug
> code?  Do you remove it before deploying to production, if so how do you
> make sure you remove it all without removing something important that
> will break your code?  Or do you use conditional execution such as:
> 
> if ($_ENV['DEGUG'] == true) {
>     var_dump($data);
> }
> 
> If so what condition are you using?  An environment variable like above,
> a constant defined elsewhere in a config file?
> 
> I think conditional execution would be easier but question if having to
> check if the debug code can run would slow down a production server, but
> the question is how much overhead really does it take to check $_ENV or
> a constant...
> 
> So I am curious to see how others deal with this.

My debug output: tracing statements, Warning: msg and Error: msg (which 
stops the run) are all localised in a ReportError diagnostic class which 
accepts a debugging level (0=no tracing o/p, +ve values enable 
progressively more o/p).

The debug level defaults to zero and can be set, via the setDebug() 
method, in any way that seems suitable for the process being debugged, 
i.e. from a command line option, via a configuration file, .... 

Each trace() method has the triggering debug level as its first argument. 
while warning() and error() methods are always active.

I always leave this in production code on the grounds that input can 
differ from what the system spec required so the ability to enable 
debugging in a production environment can be very useful. In practice the 
overhead seems to be minimal. 

ReportError also implements a circular buffer for trace messages - the 
number of messages it holds is configurable. This is very useful when 
you're trying to diagnose a once a day/once a week problem in a process 
that runs 24/7. A buffer dumps are triggered by calls on the warning() 
and error() methods - the buffer content immediately preceeds the warning 
or error message. Experience says that a straight stackdump only tells 
you where the fault is, but not what triggered it - hence the circular 
buffer, which holds that information.

In my implementation all output is to stderr, but it would be equally 
easy to configurably interface something like this to your favourite 
message logging package.

-- 
Martin    | martin at
Gregorie  | gregorie dot org

Thread

csiph-web