Well, I am not sure why you would want to do that. If you are trying to capture DBI warnings/errors, you can give the DBI handle an error handler:

$h->{RaiseError} = 1; # Turn all warnings into dies
$h->{HandleError} = sub { set_dberror(join('',@_)) };
[download]

Any errors generated by the dbh will be passed to your sub.

If you really want to capture capture all warning for specific modules, you might try:

package TrapWarnings;

my %Modules;
BEGIN { $SIG{__WARN__} = \ &trapWarning; }

sub import {
     $Modules{caller} = 1;
}

sub trapWarning {
     my $caller = caller 1;
     if ($Module{$caller}) {
          set_dberror(join('',@_))
     } else {
          warn @_
     }
}

# Example use

package Foo;

use TrapWarnings;

warn "foo";
[download]

Well that code is completely untested. The general idea is everytime you import your TrapWarnings package, it adds that package to the list of packages to trap warnings for. When a warn happens, it checks the original caller to see if its package is in the list. If so, it traps it, otherwise, just re-warns it.

This is far from ideal, but with creative use of the Carp module you might get where you want to be.

you can give the DBI handle an error handler:

$h->{RaiseError} = 1; # Turn all warnings into dies
$h->{HandleError} = sub { set_dberror(join('',@_)) };

Any errors generated by the dbh will be passed to your sub.


Errr... I don't really get it, how is this code supposed to work? won't it pass any warning to the sub, not only the dbh warnings ?

Nope, this code will pass only DBH warnings to the set_dberror sub. You do it when when you initialize your DBH handle. Although, I don't think it handles connnection errors.

Ted Young

($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)

You _could_ use Hook::LexWrap ... *grins*

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

It's interesting, but... it's overkill there. I just aim to achieve a very clean output :)

Sure I tried it. unfortunately It doesn't work; either I put

$SIG{__WARN__} = sub { set_dberror(join('',@_))};
[download]

at the beginning of the module and it changes behaviour of all programs using it; I tried too

local $SIG{__WARN__} = sub { set_dberror(join('',@_))};
[download]

at the beginning of the module, but it just has no effect at all (the dbi errors are happily sput out on STDERR).

Firstly, you can get DBI to stop spitting errors by:

$dbh->{PrintError} = 0;
[download]

Secondly, $SIG{__WARN__} doesn't automagically cover anything printed to STDERR, only things that result from a call to warn(), which happens to cause a print to STDERR.

Finally, if neither of those applies, try:

our $SIG{__WARN__} = sub { ... }
[download]

For which I'm certain I will be flamed...

radiantmatrix
require General::Disclaimer;
s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

That's a nice idea, but won't it somewhat slow down everything? I'll give it a try.

Depends on the eval :-) string eval -> slow, block eval -> as fast as any other perl snippet

Using eval of a block is the recommendation in the DBI documentation:

The recommended way to implement robust transactions in Perl applications is to use RaiseError and eval { ... } (which is very fast, unlike eval "...").