debugging trick of the week: fatal warnings

[gav^]

I apologise if this is something obvious but I only really discovered this recently. Using the pragma: use warnings FATAL => qw(all);
means that any warning will cause your script to die.

I find this really useful in debugging scripts that do a lot of data processing. It can stop those embarassing problems when you are trying to sell your client's products for undef dollars :)

In an processing script, I output the unique id of each item as it is processed, then if (when) it dies it's just a matter of digging through the database or input files to find out what's wrong with that item.

I've always considered it better to have my script die and then try to fix the data rather than having a 'robust' script that outputs gibberish in boundary cases.

Hope this helps somebody.

gav^

[perrin]

I used to do this in the pre-5.6 days with a __WARN__ handler:

$SIG{'__WARN__'} = sub { die $_[0]};

Or something along those lines. I used it when I wanted find the cause of warnings in a very long-running script. I'd start the script with -d, and when it hit a warning it would pop me into the debugger and I could check the current value of all variables, step forward, etc.

[stephen]

If you want warnings to stop your debugger if it's running, but not to actually die, this seems to work:

$SIG{'__WARN__'} = sub { warn $_[0]; $DB::single = $DB::single; $DB::s
+ingle = 1; };

It automatically slams the debugger into single-step mode every time there's a warning. (The $DB::single = $DB::single is just to keep -w happy.)

stephen