On Monday 21 January 2019 16:55:07 p...@cpan.org wrote:
> 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...
Hi Tim! Seems that HandleSetErr cannot be used. It is not called for
cases which generates warnings.
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.
