On Monday 15 April 2019 16:21:30 Tim Bunce wrote: > 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?
I do not know. Code around HandleSetErr seems to be complex. I still think that when there is already PrintError, RaiseError and PrintWarn attributes, that one RaiseWarn is missing to be API complete. > 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.
