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:22 +0000
Organization	albasani.net
Message-ID	<qagtnn$oje$2@news.albasani.net> (permalink)
References	<a2740b73-91c2-4002-9573-d0204fe2bec7@googlegroups.com> <qagtgf$oje$1@news.albasani.net>

Show all headers | View raw

On Fri, 03 May 2019 08:18:23 +0000, Martin Gregorie wrote:

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

In my case this this stuff is implemented in both C and Java, but the 
approach should be applicable to almost any programming or scripting 
language: in PHP you probably would not need the circular buffer.


-- 
Martin    | martin at
Gregorie  | gregorie dot org

Thread

csiph-web