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.
