On Sunday 20 January 2019 17:27:22 Tim Bunce wrote: > On Fri, Jan 18, 2019 at 10:47:41AM +0100, p...@cpan.org wrote: > > On Friday 18 January 2019 09:13:48 Tim Bunce wrote: > > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote: > > > > > > > > Currently DBI has only $dbh->{PrintWarn} attribute to control warnings. > > > > When is set to true (by default) all warnings from DBI driver are passed > > > > to perl's "warn" function. > > > > > > > > So I would propose to add $dbh->{RaiseWarn} attribute (off by default) > > > > to behave like $dbh->{RaiseError}, but for warnings. > > > > > > I'd like to know more about the specific use-case(s) that prompted this. > > > > Hi! The use-case is for testing code, that its SQL part does not produce > > any warning. Lot of database server supports vendor specific SQL command > > to convert warnings to errors, but there is no standard way how to do it > > driver/database independent. And because DBI reports warnings via Perl's > > warn, it is not possible to easily distinguish between DBI warnings, > > internal Perl warnings and warnings generated by other 3rd modules. > > > > So use-case is: raise DBI errors for any warning or error from database > > server and let warnings reported by 3rd modules and by Perl itself as > > is. So to ensure that database server does not produce any "problems". > > 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. > > Tim.
I'm looking at it and will try some tests... 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.