On Fri, Apr 12, 2019 at 10:22:57AM +0200, p...@cpan.org wrote: > On Monday 21 January 2019 16:55:07 p...@cpan.org wrote: > > On Sunday 20 January 2019 17:27:22 Tim Bunce wrote: > > > > > > Couldn't HandleSetErr be used for this? > > > > > > Quoting the docs at https://metacpan.org/pod/DBI#HandleSetErr > > > > > > HandleSetErr, on the other hand, is called whenever set_err() is > > > called with a defined err value, even if false. So it's not just for > > > errors, despite the name, but also warn and info states. The set_err() > > > method, and thus HandleSetErr, may be called multiple times within a > > > method and is usually invoked from deep within driver code.
> Hi Tim! Seems that HandleSetErr cannot be used. It is not called for > cases which generates warnings. Couldn't that be fixed? Tim. > On the other hand my proposed and implemented RaiseWarn is working fine. > > > Anyway, another use-case is for testing DBI SQL applications. If I write > > tests for that application which should not produce any SQL warnings, > > then with my approach RaiseWarn => 1 in DBI->connect I can simple ensure > > that test fails if something unexpected happens. > > > > With HandleSetErr it is maybe possible too, but needs non-trivial logic > > for writing code ref subroutine and is not so simple and obvious for > > people who read test code. With RaiseWarn => 1 I simple declare what > > should happen when warning is generated; similarly like for already > > existing RaiseError. > > > > Reason why I chose RaiseWarn is because there is already PrintWarn, > > PrintError and RaiseError attributes. So RaiseWarn just use same naming > > and logic pattern.
