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.
