RaiseWarn attribute for DBI

Hello!

What do you think about adding a new attribute $dbh->{RaiseWarn} which
cause that warnings reported by DBI drivers would behave like errors?

For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError}
attributes. First one is by default true and second one by default
false. When PrintWarn is true, then all error from DBI driver are passed
to perl's "warn" function and when RaiseError is true, then errors are
passed to perl's "die" function. (Plus there is ability to register own
error handler function)

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 have implemented this attribute and patch is there:
https://github.com/perl5-dbi/dbi/pull/71/files
0
pali
1/17/2019 9:02:39 AM
perl.dbi.dev 1960 articles. 0 followers. Follow

18 Replies
242 Views

Similar Articles

[PageSpeed] 50

--5c40498d_277e6e2a_48e4
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I don't see the benefit, Print* should die and I'd personally would release a major release and change the defaults as a breaking change: PrintError false, RaiseError true.
Can you name a use case and how to differ between an error and a warning at the error handling side?

Best regards, Alex


On 2019-01-17 10:04, pali@cpan.org wrote:
> Hello! What do you think about adding a new attribute $dbh->{RaiseWarn} which cause that warnings reported by DBI drivers would behave like errors? For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one is by default true and second one by default false. When PrintWarn is true, then all error from DBI driver are passed to perl's "warn" function and when RaiseError is true, then errors are passed to perl's "die" function. (Plus there is ability to register own error handler function) 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 have implemented this attribute and patch is there: https://github.com/perl5-dbi/dbi/pull/71/files 



--5c40498d_277e6e2a_48e4
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>I don't see the benefit, Print* should die and I'd personally would =
release a major release and change the defaults as a breaking change: Pri=
ntError false, RaiseError true.</div>
<div>Can you name a use case and how to differ between an error and a war=
ning at the error handling side=3F</div>
<div>&nbsp;</div>
<div class=3D=22syno-mc-signature=22>
<div>Best regards, Alex</div>
</div>
<div>&nbsp;</div>
<div class=3D=22=22>
<div>On 2019-01-17 10:04, pali=40cpan.org wrote:</div>
<blockquote class=3D=22syno-mc-blockquote=22 style=3D=22padding-left: 5px=
; margin-left: 5px; border-left: =23c8d2dc 2px solid;=22>
<pre>Hello=21

What do you think about adding a new attribute =24dbh-&gt;=7BRaiseWarn=7D=
 which
cause that warnings reported by DBI drivers would behave like errors=3F

=46or errors DBI has there =24dbh-&gt;=7BPrintError=7D and =24dbh-&gt;=7B=
RaiseError=7D
attributes. =46irst one is by default true and second one by default
false. When PrintWarn is true, then all error from DBI driver are passed
to perl's =22warn=22 function and when RaiseError is true, then errors ar=
e
passed to perl's =22die=22 function. (Plus there is ability to register o=
wn
error handler function)

Currently DBI has only =24dbh-&gt;=7BPrintWarn=7D attribute to control wa=
rnings.
When is set to true (by default) all warnings from DBI driver are passed
to perl's =22warn=22 function.

So I would propose to add =24dbh-&gt;=7BRaiseWarn=7D attribute (off by de=
fault)
to behave like =24dbh-&gt;=7BRaiseError=7D, but for warnings.

I have implemented this attribute and patch is there:
https://github.com/perl5-dbi/dbi/pull/71/files
</pre></blockquote>
</div>


--5c40498d_277e6e2a_48e4--
0
alex
1/17/2019 9:23:25 AM
On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote:
> I don't see the benefit, Print* should die

This would break existing API of DBI. Print just prints and Raise dies.
This cannot be changed as there are many applications which depends on
this API.

> and I'd personally would release a major release and change the defaults as a breaking change: PrintError false, RaiseError true.

> Can you name a use case and how to differ between an error and a warning at the error handling side?

It is up to the DBI driver or database server what would result in is a
warning and what in an error.

> Best regards, Alex
> 
> 
> On 2019-01-17 10:04, pali@cpan.org wrote:
> > Hello! What do you think about adding a new attribute $dbh->{RaiseWarn} which cause that warnings reported by DBI drivers would behave like errors? For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one is by default true and second one by default false. When PrintWarn is true, then all error from DBI driver are passed to perl's "warn" function and when RaiseError is true, then errors are passed to perl's "die" function. (Plus there is ability to register own error handler function) 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 have implemented this attribute and patch is there: https://github.com/perl5-dbi/dbi/pull/71/files 
0
pali
1/17/2019 9:53:23 AM
--5c40539e_155cc1e3_6582
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm aware of that, semantic versioning and major versions exist to handle API breakage.

My question is how to detect if an exception is because of a warn or a die when RaiseWarn is true.

Best regards, Alex

On 2019-01-17 10:53, pali@cpan.org wrote:
> On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I don't see the benefit, Print* should die This would break existing API of DBI. Print just prints and Raise dies. This cannot be changed as there are many applications which depends on this API. > and I'd personally would release a major release and change the defaults as a breaking change: PrintError false, RaiseError true. > Can you name a use case and how to differ between an error and a warning at the error handling side? It is up to the DBI driver or database server what would result in is a warning and what in an error. > Best regards, Alex > > > On 2019-01-17 10:04, pali@cpan.org wrote: > > Hello! What do you think about adding a new attribute $dbh->{RaiseWarn} which cause that warnings reported by DBI drivers would behave like errors? For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one is by default true and second one by default false. When PrintWarn is true, the
 n all er

ror from DBI driver are passed to perl's "warn" function and when RaiseError is true, then errors are passed to perl's "die" function. (Plus there is ability to register own error handler function) 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 have implemented this attribute and patch is there: https://github.com/perl5-dbi/dbi/pull/71/files 



--5c40539e_155cc1e3_6582
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>I'm aware of that, semantic versioning and major versions exist to h=
andle API breakage.</div>
<div>&nbsp;</div>
<div>My question is how to detect if an exception is because of a warn or=
 a die when RaiseWarn is true.</div>
<div>&nbsp;</div>
<div class=3D=22syno-mc-signature=22>
<div>Best regards, Alex</div>
</div>
<div class=3D=22=22>
<div>On 2019-01-17 10:53, pali=40cpan.org wrote:</div>
<blockquote class=3D=22syno-mc-blockquote=22 style=3D=22padding-left: 5px=
; margin-left: 5px; border-left: =23c8d2dc 2px solid;=22>
<pre>On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote:
&gt; I don't see the benefit, Print* should die

This would break existing API of DBI. Print just prints and Raise dies.
This cannot be changed as there are many applications which depends on
this API.

&gt; and I'd personally would release a major release and change the defa=
ults as a breaking change: PrintError false, RaiseError true.

&gt; Can you name a use case and how to differ between an error and a war=
ning at the error handling side=3F

It is up to the DBI driver or database server what would result in is a
warning and what in an error.

&gt; Best regards, Alex
&gt;  =20
&gt;  =20
&gt; On 2019-01-17 10:04, pali=40cpan.org wrote:
&gt; &gt; Hello=21 What do you think about adding a new attribute =24dbh-=
&gt;=7BRaiseWarn=7D which cause that warnings reported by DBI drivers wou=
ld behave like errors=3F =46or errors DBI has there =24dbh-&gt;=7BPrintEr=
ror=7D and =24dbh-&gt;=7BRaiseError=7D attributes. =46irst one is by defa=
ult true and second one by default false. When PrintWarn is true, then al=
l error from DBI driver are passed to perl's =22warn=22 function and when=
 RaiseError is true, then errors are passed to perl's =22die=22 function.=
 (Plus there is ability to register own error handler function) Currently=
 DBI has only =24dbh-&gt;=7BPrintWarn=7D attribute to control warnings. W=
hen is set to true (by default) all warnings from DBI driver are passed t=
o perl's =22warn=22 function. So I would propose to add =24dbh-&gt;=7BRai=
seWarn=7D attribute (off by default) to behave like =24dbh-&gt;=7BRaiseEr=
ror=7D, but for warnings. I have implemented this attribute and patch is =
there: https://github.com/perl5-dbi/dbi/pull/71/files  =20
</pre></blockquote>
</div>


--5c40539e_155cc1e3_6582--
0
alex
1/17/2019 10:06:22 AM
On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote:
> I'm aware of that, semantic versioning and major versions exist to handle=
 API breakage.

Such thing is unsupported by CPAN clients. So we cannot use it.

Anyway, this is question for Tim as DBI maintainer. But I guess he does
not want to change API of DBI.

> My question is how to detect if an exception is because of a warn or a di=
e when RaiseWarn is true.

I guess you can use $dbh->err() method.
See: https://metacpan.org/pod/DBI#err

A driver may return 0 from err() to indicate a warning condition after a
method call. Similarly, a driver may return an empty string to indicate
a 'success with information' condition. In both these cases the value is
false but not undef.

Note that 'success with information' is not warning and therefore DBI's
PrintWarn or RaiseWarn ignores them.

> Best regards, Alex
>=20
> On 2019-01-17 10:53, pali@cpan.org wrote:
> > On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I don=
't see the benefit, Print* should die This would break existing API of DBI.=
 Print just prints and Raise dies. This cannot be changed as there are many=
 applications which depends on this API. > and I'd personally would release=
 a major release and change the defaults as a breaking change: PrintError f=
alse, RaiseError true. > Can you name a use case and how to differ between =
an error and a warning at the error handling side? It is up to the DBI driv=
er or database server what would result in is a warning and what in an erro=
r. > Best regards, Alex > > > On 2019-01-17 10:04, pali@cpan.org wrote: > >=
 Hello! What do you think about adding a new attribute $dbh->{RaiseWarn} wh=
ich cause that warnings reported by DBI drivers would behave like errors? F=
or errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError} attribute=
s. First one is by default true and second one by default false. When Print=
Warn is true, the
>  n all er
>=20
> ror from DBI driver are passed to perl's "warn" function and when RaiseEr=
ror is true, then errors are passed to perl's "die" function. (Plus there i=
s ability to register own error handler function) Currently DBI has only $d=
bh->{PrintWarn} attribute to control warnings. When is set to true (by defa=
ult) 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 beha=
ve like $dbh->{RaiseError}, but for warnings. I have implemented this attri=
bute and patch is there: https://github.com/perl5-dbi/dbi/pull/71/files=20
>=20
>=20
0
pali
1/17/2019 10:43:16 AM
R2VuZXJhbGx5IHNwZWFraW5nLCBEQkkgaXMgb25lIG9mIHRob3NlIHRoaW5ncyB3aGVyZSBi
YWNrd2FyZHMgY29tcGF0aWJpbGl0eSANCnNob3VsZCBiZSB0aGUgaGlnaGVzdCBjb25jZXJu
IGFmdGVyIHNlY3VyaXR5LiAgVGhlcmUgaXMgYSB0aW1lIGFuZCBwbGFjZSB0byANCmJyZWFr
IGNvbXBhdGliaWxpdHksIGFuZCB0aGlzIFByaW50L1JhaXNlIHRoaW5nIHNlZW1zIHdheSB0
b28gbWlub3IgdG8gbWUgZm9yIA0KdGhhdC4gIEkgc3VwcG9ydCB0aGUgdmVyc2lvbiBvZiB0
aGlzIHRoYXQgaXMgYmFja3dhcmRzLWNvbXBhdGlibGUgYW5kIG5vdCB0aGUgDQpicmVha2lu
ZyB2ZXJzaW9uLiAtLSBEYXJyZW4gRHVuY2FuDQoNCk9uIDIwMTktMDEtMTcgMjo0MyBBTSwg
cGFsaUBjcGFuLm9yZyB3cm90ZToNCj4gT24gVGh1cnNkYXkgMTcgSmFudWFyeSAyMDE5IDEx
OjA2OjIyIEFsZXhhbmRlciBIYXJ0bWFpZXIgd3JvdGU6DQo+PiBJJ20gYXdhcmUgb2YgdGhh
dCwgc2VtYW50aWMgdmVyc2lvbmluZyBhbmQgbWFqb3IgdmVyc2lvbnMgZXhpc3QgdG8gaGFu
ZGxlIEFQSSBicmVha2FnZS4NCj4gDQo+IFN1Y2ggdGhpbmcgaXMgdW5zdXBwb3J0ZWQgYnkg
Q1BBTiBjbGllbnRzLiBTbyB3ZSBjYW5ub3QgdXNlIGl0Lg0KPiANCj4gQW55d2F5LCB0aGlz
IGlzIHF1ZXN0aW9uIGZvciBUaW0gYXMgREJJIG1haW50YWluZXIuIEJ1dCBJIGd1ZXNzIGhl
IGRvZXMNCj4gbm90IHdhbnQgdG8gY2hhbmdlIEFQSSBvZiBEQkkuDQo+IA0KPj4gTXkgcXVl
c3Rpb24gaXMgaG93IHRvIGRldGVjdCBpZiBhbiBleGNlcHRpb24gaXMgYmVjYXVzZSBvZiBh
IHdhcm4gb3IgYSBkaWUgd2hlbiBSYWlzZVdhcm4gaXMgdHJ1ZS4NCj4gDQo+IEkgZ3Vlc3Mg
eW91IGNhbiB1c2UgJGRiaC0+ZXJyKCkgbWV0aG9kLg0KPiBTZWU6IGh0dHBzOi8vbWV0YWNw
YW4ub3JnL3BvZC9EQkkjZXJyDQo+IA0KPiBBIGRyaXZlciBtYXkgcmV0dXJuIDAgZnJvbSBl
cnIoKSB0byBpbmRpY2F0ZSBhIHdhcm5pbmcgY29uZGl0aW9uIGFmdGVyIGENCj4gbWV0aG9k
IGNhbGwuIFNpbWlsYXJseSwgYSBkcml2ZXIgbWF5IHJldHVybiBhbiBlbXB0eSBzdHJpbmcg
dG8gaW5kaWNhdGUNCj4gYSAnc3VjY2VzcyB3aXRoIGluZm9ybWF0aW9uJyBjb25kaXRpb24u
IEluIGJvdGggdGhlc2UgY2FzZXMgdGhlIHZhbHVlIGlzDQo+IGZhbHNlIGJ1dCBub3QgdW5k
ZWYuDQo+IA0KPiBOb3RlIHRoYXQgJ3N1Y2Nlc3Mgd2l0aCBpbmZvcm1hdGlvbicgaXMgbm90
IHdhcm5pbmcgYW5kIHRoZXJlZm9yZSBEQkkncw0KPiBQcmludFdhcm4gb3IgUmFpc2VXYXJu
IGlnbm9yZXMgdGhlbS4NCj4gDQo+PiBCZXN0IHJlZ2FyZHMsIEFsZXgNCj4+DQo+PiBPbiAy
MDE5LTAxLTE3IDEwOjUzLCBwYWxpQGNwYW4ub3JnIHdyb3RlOg0KPj4+IE9uIFRodXJzZGF5
IDE3IEphbnVhcnkgMjAxOSAxMDoyMzoyNSBBbGV4YW5kZXIgSGFydG1haWVyIHdyb3RlOiA+
IEkgZG9uJ3Qgc2VlIHRoZSBiZW5lZml0LCBQcmludCogc2hvdWxkIGRpZSBUaGlzIHdvdWxk
IGJyZWFrIGV4aXN0aW5nIEFQSSBvZiBEQkkuIFByaW50IGp1c3QgcHJpbnRzIGFuZCBSYWlz
ZSBkaWVzLiBUaGlzIGNhbm5vdCBiZSBjaGFuZ2VkIGFzIHRoZXJlIGFyZSBtYW55IGFwcGxp
Y2F0aW9ucyB3aGljaCBkZXBlbmRzIG9uIHRoaXMgQVBJLiA+IGFuZCBJJ2QgcGVyc29uYWxs
eSB3b3VsZCByZWxlYXNlIGEgbWFqb3IgcmVsZWFzZSBhbmQgY2hhbmdlIHRoZSBkZWZhdWx0
cyBhcyBhIGJyZWFraW5nIGNoYW5nZTogUHJpbnRFcnJvciBmYWxzZSwgUmFpc2VFcnJvciB0
cnVlLiA+IENhbiB5b3UgbmFtZSBhIHVzZSBjYXNlIGFuZCBob3cgdG8gZGlmZmVyIGJldHdl
ZW4gYW4gZXJyb3IgYW5kIGEgd2FybmluZyBhdCB0aGUgZXJyb3IgaGFuZGxpbmcgc2lkZT8g
SXQgaXMgdXAgdG8gdGhlIERCSSBkcml2ZXIgb3IgZGF0YWJhc2Ugc2VydmVyIHdoYXQgd291
bGQgcmVzdWx0IGluIGlzIGEgd2FybmluZyBhbmQgd2hhdCBpbiBhbiBlcnJvci4gPiBCZXN0
IHJlZ2FyZHMsIEFsZXggPiA+ID4gT24gMjAxOS0wMS0xNyAxMDowNCwgcGFsaUBjcGFuLm9y
ZyB3cm90ZTogPiA+IEhlbGxvISBXaGF0IGRvIHlvdSB0aGluayBhYm91dCBhZGRpbmcgYSBu
ZXcgYXR0cmlidXRlICRkYmgtPntSYWlzZVdhcm59IHdoaWNoIGNhdXNlIHRoYXQgd2Fybmlu
Z3MgcmVwb3J0ZWQgYnkgREJJIGRyaXZlcnMgd291bGQgYmVoYXZlIGxpa2UgZXJyb3JzPyBG
b3IgZXJyb3JzIERCSSBoYXMgdGhlcmUgJGRiaC0+e1ByaW50RXJyb3J9IGFuZCAkZGJoLT57
UmFpc2VFcnJvcn0gYXR0cmlidXRlcy4gRmlyc3Qgb25lIGlzIGJ5IGRlZmF1bHQgdHJ1ZSBh
bmQgc2Vjb25kIG9uZSBieSBkZWZhdWx0IGZhbHNlLiBXaGVuIFByaW50V2FybiBpcyB0cnVl
LCB0aGUNCj4+ICAgbiBhbGwgZXINCj4+DQo+PiByb3IgZnJvbSBEQkkgZHJpdmVyIGFyZSBw
YXNzZWQgdG8gcGVybCdzICJ3YXJuIiBmdW5jdGlvbiBhbmQgd2hlbiBSYWlzZUVycm9yIGlz
IHRydWUsIHRoZW4gZXJyb3JzIGFyZSBwYXNzZWQgdG8gcGVybCdzICJkaWUiIGZ1bmN0aW9u
LiAoUGx1cyB0aGVyZSBpcyBhYmlsaXR5IHRvIHJlZ2lzdGVyIG93biBlcnJvciBoYW5kbGVy
IGZ1bmN0aW9uKSBDdXJyZW50bHkgREJJIGhhcyBvbmx5ICRkYmgtPntQcmludFdhcm59IGF0
dHJpYnV0ZSB0byBjb250cm9sIHdhcm5pbmdzLiBXaGVuIGlzIHNldCB0byB0cnVlIChieSBk
ZWZhdWx0KSBhbGwgd2FybmluZ3MgZnJvbSBEQkkgZHJpdmVyIGFyZSBwYXNzZWQgdG8gcGVy
bCdzICJ3YXJuIiBmdW5jdGlvbi4gU28gSSB3b3VsZCBwcm9wb3NlIHRvIGFkZCAkZGJoLT57
UmFpc2VXYXJufSBhdHRyaWJ1dGUgKG9mZiBieSBkZWZhdWx0KSB0byBiZWhhdmUgbGlrZSAk
ZGJoLT57UmFpc2VFcnJvcn0sIGJ1dCBmb3Igd2FybmluZ3MuIEkgaGF2ZSBpbXBsZW1lbnRl
ZCB0aGlzIGF0dHJpYnV0ZSBhbmQgcGF0Y2ggaXMgdGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNv
bS9wZXJsNS1kYmkvZGJpL3B1bGwvNzEvZmlsZXMNCj4+DQo+Pg0KPiANCg0K
0
darren
1/17/2019 7:02:51 PM
Personally I do not like changing Print/Raise. It is documented,
implementation seems to match documentation, it is without bugs and
current behavior is usable.

Anyway, back to my question about RaiseWarn. Do you think that it make
sense to have it in DBI?

On Thursday 17 January 2019 11:02:51 Darren Duncan wrote:
> Generally speaking, DBI is one of those things where backwards compatibil=
ity
> should be the highest concern after security.  There is a time and place =
to
> break compatibility, and this Print/Raise thing seems way too minor to me
> for that.  I support the version of this that is backwards-compatible and
> not the breaking version. -- Darren Duncan
>=20
> On 2019-01-17 2:43 AM, pali@cpan.org wrote:
> > On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote:
> > > I'm aware of that, semantic versioning and major versions exist to ha=
ndle API breakage.
> >=20
> > Such thing is unsupported by CPAN clients. So we cannot use it.
> >=20
> > Anyway, this is question for Tim as DBI maintainer. But I guess he does
> > not want to change API of DBI.
> >=20
> > > My question is how to detect if an exception is because of a warn or =
a die when RaiseWarn is true.
> >=20
> > I guess you can use $dbh->err() method.
> > See: https://metacpan.org/pod/DBI#err
> >=20
> > A driver may return 0 from err() to indicate a warning condition after a
> > method call. Similarly, a driver may return an empty string to indicate
> > a 'success with information' condition. In both these cases the value is
> > false but not undef.
> >=20
> > Note that 'success with information' is not warning and therefore DBI's
> > PrintWarn or RaiseWarn ignores them.
> >=20
> > > Best regards, Alex
> > >=20
> > > On 2019-01-17 10:53, pali@cpan.org wrote:
> > > > On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I=
 don't see the benefit, Print* should die This would break existing API of =
DBI. Print just prints and Raise dies. This cannot be changed as there are =
many applications which depends on this API. > and I'd personally would rel=
ease a major release and change the defaults as a breaking change: PrintErr=
or false, RaiseError true. > Can you name a use case and how to differ betw=
een an error and a warning at the error handling side? It is up to the DBI =
driver or database server what would result in is a warning and what in an =
error. > Best regards, Alex > > > On 2019-01-17 10:04, pali@cpan.org wrote:=
 > > Hello! What do you think about adding a new attribute $dbh->{RaiseWarn=
} which cause that warnings reported by DBI drivers would behave like error=
s? For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError} attri=
butes. First one is by default true and second one by default false. When P=
rintWarn is true, the
> > >   n all er
> > >=20
> > > ror from DBI driver are passed to perl's "warn" function and when Rai=
seError is true, then errors are passed to perl's "die" function. (Plus the=
re is ability to register own error handler function) Currently DBI has onl=
y $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 have implemented this a=
ttribute and patch is there: https://github.com/perl5-dbi/dbi/pull/71/files
> > >=20
> > >=20
> >=20
>=20
0
pali
1/17/2019 10:57:07 PM
I didn=E2=80=98t want to start a discussion about deprecation because I know=
 the opinion about that for most Perl 5 developers.

But strictures and its use in Moo showed that exceptions from warnings aren=E2=
=80=98t welcome.
You can install a warn handler in your code without requiring any change. Ad=
ding another option raises the number of combinations.

As I don=E2=80=98t see any benefit and no examples where given I=E2=80=98m a=
gainst it.

> Am 17.01.2019 um 23:57 schrieb pali@cpan.org:
>=20
> Personally I do not like changing Print/Raise. It is documented,
> implementation seems to match documentation, it is without bugs and
> current behavior is usable.
>=20
> Anyway, back to my question about RaiseWarn. Do you think that it make
> sense to have it in DBI?
>=20
>> On Thursday 17 January 2019 11:02:51 Darren Duncan wrote:
>> Generally speaking, DBI is one of those things where backwards compatibil=
ity
>> should be the highest concern after security.  There is a time and place t=
o
>> break compatibility, and this Print/Raise thing seems way too minor to me=

>> for that.  I support the version of this that is backwards-compatible and=

>> not the breaking version. -- Darren Duncan
>>=20
>>> On 2019-01-17 2:43 AM, pali@cpan.org wrote:
>>>> On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote:
>>>> I'm aware of that, semantic versioning and major versions exist to hand=
le API breakage.
>>>=20
>>> Such thing is unsupported by CPAN clients. So we cannot use it.
>>>=20
>>> Anyway, this is question for Tim as DBI maintainer. But I guess he does
>>> not want to change API of DBI.
>>>=20
>>>> My question is how to detect if an exception is because of a warn or a d=
ie when RaiseWarn is true.
>>>=20
>>> I guess you can use $dbh->err() method.
>>> See: https://metacpan.org/pod/DBI#err
>>>=20
>>> A driver may return 0 from err() to indicate a warning condition after a=

>>> method call. Similarly, a driver may return an empty string to indicate
>>> a 'success with information' condition. In both these cases the value is=

>>> false but not undef.
>>>=20
>>> Note that 'success with information' is not warning and therefore DBI's
>>> PrintWarn or RaiseWarn ignores them.
>>>=20
>>>> Best regards, Alex
>>>>=20
>>>>> On 2019-01-17 10:53, pali@cpan.org wrote:
>>>>> On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I do=
n't see the benefit, Print* should die This would break existing API of DBI.=
 Print just prints and Raise dies. This cannot be changed as there are many a=
pplications which depends on this API. > and I'd personally would release a m=
ajor release and change the defaults as a breaking change: PrintError false,=
 RaiseError true. > Can you name a use case and how to differ between an err=
or and a warning at the error handling side? It is up to the DBI driver or d=
atabase server what would result in is a warning and what in an error. > Bes=
t regards, Alex > > > On 2019-01-17 10:04, pali@cpan.org wrote: > > Hello! W=
hat do you think about adding a new attribute $dbh->{RaiseWarn} which cause t=
hat warnings reported by DBI drivers would behave like errors? For errors DB=
I has there $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one i=
s by default true and second one by default false. When PrintWarn is true, t=
he
>>>>  n all er
>>>>=20
>>>> ror from DBI driver are passed to perl's "warn" function and when Raise=
Error is true, then errors are passed to perl's "die" function. (Plus there i=
s ability to register own error handler function) Currently DBI has only $db=
h->{PrintWarn} attribute to control warnings. When is set to true (by defaul=
t) all warnings from DBI driver are passed to perl's "warn" function. So I w=
ould propose to add $dbh->{RaiseWarn} attribute (off by default) to behave l=
ike $dbh->{RaiseError}, but for warnings. I have implemented this attribute a=
nd patch is there: https://github.com/perl5-dbi/dbi/pull/71/files
>>>>=20
>>>>=20
>>>=20
>>=20
0
alex
1/17/2019 11:10:35 PM
--000000000000bd13bb057fafb2f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

While I'm a staunch opponent of fatal warnings in general, and I believe
Pali has voiced concern with them as well, this is somewhat unrelated as it
has nothing to do with the core warnings pragma and categories, and is
simply an *option* to cause DBI to exhibit different behavior which it
currently cannot. As such I think it's a fine idea.

-Dan

On Thu, Jan 17, 2019 at 6:20 PM Alexander Hartmaier <alex@hartmaier.priv.at=
>
wrote:

> I didn=E2=80=98t want to start a discussion about deprecation because I k=
now the
> opinion about that for most Perl 5 developers.
>
> But strictures and its use in Moo showed that exceptions from warnings
> aren=E2=80=98t welcome.
> You can install a warn handler in your code without requiring any change.
> Adding another option raises the number of combinations.
>
> As I don=E2=80=98t see any benefit and no examples where given I=E2=80=98=
m against it.
>
> > Am 17.01.2019 um 23:57 schrieb pali@cpan.org:
> >
> > Personally I do not like changing Print/Raise. It is documented,
> > implementation seems to match documentation, it is without bugs and
> > current behavior is usable.
> >
> > Anyway, back to my question about RaiseWarn. Do you think that it make
> > sense to have it in DBI?
> >
> >> On Thursday 17 January 2019 11:02:51 Darren Duncan wrote:
> >> Generally speaking, DBI is one of those things where backwards
> compatibility
> >> should be the highest concern after security.  There is a time and
> place to
> >> break compatibility, and this Print/Raise thing seems way too minor to
> me
> >> for that.  I support the version of this that is backwards-compatible
> and
> >> not the breaking version. -- Darren Duncan
> >>
> >>> On 2019-01-17 2:43 AM, pali@cpan.org wrote:
> >>>> On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote:
> >>>> I'm aware of that, semantic versioning and major versions exist to
> handle API breakage.
> >>>
> >>> Such thing is unsupported by CPAN clients. So we cannot use it.
> >>>
> >>> Anyway, this is question for Tim as DBI maintainer. But I guess he do=
es
> >>> not want to change API of DBI.
> >>>
> >>>> My question is how to detect if an exception is because of a warn or
> a die when RaiseWarn is true.
> >>>
> >>> I guess you can use $dbh->err() method.
> >>> See: https://metacpan.org/pod/DBI#err
> >>>
> >>> A driver may return 0 from err() to indicate a warning condition afte=
r
> a
> >>> method call. Similarly, a driver may return an empty string to indica=
te
> >>> a 'success with information' condition. In both these cases the value
> is
> >>> false but not undef.
> >>>
> >>> Note that 'success with information' is not warning and therefore DBI=
's
> >>> PrintWarn or RaiseWarn ignores them.
> >>>
> >>>> Best regards, Alex
> >>>>
> >>>>> On 2019-01-17 10:53, pali@cpan.org wrote:
> >>>>> On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I
> don't see the benefit, Print* should die This would break existing API of
> DBI. Print just prints and Raise dies. This cannot be changed as there ar=
e
> many applications which depends on this API. > and I'd personally would
> release a major release and change the defaults as a breaking change:
> PrintError false, RaiseError true. > Can you name a use case and how to
> differ between an error and a warning at the error handling side? It is u=
p
> to the DBI driver or database server what would result in is a warning an=
d
> what in an error. > Best regards, Alex > > > On 2019-01-17 10:04,
> pali@cpan.org wrote: > > Hello! What do you think about adding a new
> attribute $dbh->{RaiseWarn} which cause that warnings reported by DBI
> drivers would behave like errors? For errors DBI has there
> $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one is by
> default true and second one by default false. When PrintWarn is true, the
> >>>>  n all er
> >>>>
> >>>> ror from DBI driver are passed to perl's "warn" function and when
> RaiseError is true, then errors are passed to perl's "die" function. (Plu=
s
> there is ability to register own error handler function) Currently DBI ha=
s
> 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 have
> implemented this attribute and patch is there:
> https://github.com/perl5-dbi/dbi/pull/71/files
> >>>>
> >>>>
> >>>
> >>
>

--000000000000bd13bb057fafb2f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While I&#39;m a staunch opponent of fatal warnings in gene=
ral, and I believe Pali has voiced concern with them as well, this is somew=
hat unrelated as it has nothing to do with the core warnings pragma and cat=
egories, and is simply an *option* to cause DBI to exhibit different behavi=
or which it currently cannot. As such I think it&#39;s a fine idea.<div><br=
></div><div>-Dan</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Thu, Jan 17, 2019 at 6:20 PM Alexander Hartmaier &=
lt;<a href=3D"mailto:alex@hartmaier.priv.at">alex@hartmaier.priv.at</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I didn=
=E2=80=98t want to start a discussion about deprecation because I know the =
opinion about that for most Perl 5 developers.<br>
<br>
But strictures and its use in Moo showed that exceptions from warnings aren=
=E2=80=98t welcome.<br>
You can install a warn handler in your code without requiring any change. A=
dding another option raises the number of combinations.<br>
<br>
As I don=E2=80=98t see any benefit and no examples where given I=E2=80=98m =
against it.<br>
<br>
&gt; Am 17.01.2019 um 23:57 schrieb <a href=3D"mailto:pali@cpan.org" target=
=3D"_blank">pali@cpan.org</a>:<br>
&gt; <br>
&gt; Personally I do not like changing Print/Raise. It is documented,<br>
&gt; implementation seems to match documentation, it is without bugs and<br=
>
&gt; current behavior is usable.<br>
&gt; <br>
&gt; Anyway, back to my question about RaiseWarn. Do you think that it make=
<br>
&gt; sense to have it in DBI?<br>
&gt; <br>
&gt;&gt; On Thursday 17 January 2019 11:02:51 Darren Duncan wrote:<br>
&gt;&gt; Generally speaking, DBI is one of those things where backwards com=
patibility<br>
&gt;&gt; should be the highest concern after security.=C2=A0 There is a tim=
e and place to<br>
&gt;&gt; break compatibility, and this Print/Raise thing seems way too mino=
r to me<br>
&gt;&gt; for that.=C2=A0 I support the version of this that is backwards-co=
mpatible and<br>
&gt;&gt; not the breaking version. -- Darren Duncan<br>
&gt;&gt; <br>
&gt;&gt;&gt; On 2019-01-17 2:43 AM, <a href=3D"mailto:pali@cpan.org" target=
=3D"_blank">pali@cpan.org</a> wrote:<br>
&gt;&gt;&gt;&gt; On Thursday 17 January 2019 11:06:22 Alexander Hartmaier w=
rote:<br>
&gt;&gt;&gt;&gt; I&#39;m aware of that, semantic versioning and major versi=
ons exist to handle API breakage.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Such thing is unsupported by CPAN clients. So we cannot use it=
..<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Anyway, this is question for Tim as DBI maintainer. But I gues=
s he does<br>
&gt;&gt;&gt; not want to change API of DBI.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; My question is how to detect if an exception is because of=
 a warn or a die when RaiseWarn is true.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; I guess you can use $dbh-&gt;err() method.<br>
&gt;&gt;&gt; See: <a href=3D"https://metacpan.org/pod/DBI#err" rel=3D"noref=
errer" target=3D"_blank">https://metacpan.org/pod/DBI#err</a><br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; A driver may return 0 from err() to indicate a warning conditi=
on after a<br>
&gt;&gt;&gt; method call. Similarly, a driver may return an empty string to=
 indicate<br>
&gt;&gt;&gt; a &#39;success with information&#39; condition. In both these =
cases the value is<br>
&gt;&gt;&gt; false but not undef.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Note that &#39;success with information&#39; is not warning an=
d therefore DBI&#39;s<br>
&gt;&gt;&gt; PrintWarn or RaiseWarn ignores them.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; Best regards, Alex<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; On 2019-01-17 10:53, <a href=3D"mailto:pali@cpan.org" =
target=3D"_blank">pali@cpan.org</a> wrote:<br>
&gt;&gt;&gt;&gt;&gt; On Thursday 17 January 2019 10:23:25 Alexander Hartmai=
er wrote: &gt; I don&#39;t see the benefit, Print* should die This would br=
eak existing API of DBI. Print just prints and Raise dies. This cannot be c=
hanged as there are many applications which depends on this API. &gt; and I=
&#39;d personally would release a major release and change the defaults as =
a breaking change: PrintError false, RaiseError true. &gt; Can you name a u=
se case and how to differ between an error and a warning at the error handl=
ing side? It is up to the DBI driver or database server what would result i=
n is a warning and what in an error. &gt; Best regards, Alex &gt; &gt; &gt;=
 On 2019-01-17 10:04, <a href=3D"mailto:pali@cpan.org" target=3D"_blank">pa=
li@cpan.org</a> wrote: &gt; &gt; Hello! What do you think about adding a ne=
w attribute $dbh-&gt;{RaiseWarn} which cause that warnings reported by DBI =
drivers would behave like errors? For errors DBI has there $dbh-&gt;{PrintE=
rror} and $dbh-&gt;{RaiseError} attributes. First one is by default true an=
d second one by default false. When PrintWarn is true, the<br>
&gt;&gt;&gt;&gt;=C2=A0 n all er<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; ror from DBI driver are passed to perl&#39;s &quot;warn&qu=
ot; function and when RaiseError is true, then errors are passed to perl&#3=
9;s &quot;die&quot; function. (Plus there is ability to register own error =
handler function) Currently DBI has only $dbh-&gt;{PrintWarn} attribute to =
control warnings. When is set to true (by default) all warnings from DBI dr=
iver are passed to perl&#39;s &quot;warn&quot; function. So I would propose=
 to add $dbh-&gt;{RaiseWarn} attribute (off by default) to behave like $dbh=
-&gt;{RaiseError}, but for warnings. I have implemented this attribute and =
patch is there: <a href=3D"https://github.com/perl5-dbi/dbi/pull/71/files" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/perl5-dbi/dbi/pull/=
71/files</a><br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt; <br>
&gt;&gt; <br>
</blockquote></div>

--000000000000bd13bb057fafb2f2--
0
grinnz
1/17/2019 11:24:26 PM
On Thu, Jan 17, 2019 at 10:02:39AM +0100, pali@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.

Tim.

p.s. Re the compatibility topic in this thread: there will be no
breaking changes to DBI.
0
Tim
1/18/2019 9:13:48 AM
On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> On Thu, Jan 17, 2019 at 10:02:39AM +0100, pali@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".
0
pali
1/18/2019 9:47:41 AM
--000000000000a0476a057fbda0ca
Content-Type: text/plain; charset="UTF-8"

As a side note, I have in the past thought a HandleWarn option may be
useful, for instance to log warnings from the database or other custom
behavior. It could also be used to throw exceptions.

-Dan

On Thu, Jan 17, 2019 at 4:03 AM <pali@cpan.org> wrote:

> Hello!
>
> What do you think about adding a new attribute $dbh->{RaiseWarn} which
> cause that warnings reported by DBI drivers would behave like errors?
>
> For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError}
> attributes. First one is by default true and second one by default
> false. When PrintWarn is true, then all error from DBI driver are passed
> to perl's "warn" function and when RaiseError is true, then errors are
> passed to perl's "die" function. (Plus there is ability to register own
> error handler function)
>
> 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 have implemented this attribute and patch is there:
> https://github.com/perl5-dbi/dbi/pull/71/files
>

--000000000000a0476a057fbda0ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As a side note, I have in the past thought a HandleWarn op=
tion may be useful, for instance to log warnings from the database or other=
 custom behavior. It could also be used to throw exceptions.<div><br></div>=
<div>-Dan</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Thu, Jan 17, 2019 at 4:03 AM &lt;<a href=3D"mailto:pali@=
cpan.org">pali@cpan.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">Hello!<br>
<br>
What do you think about adding a new attribute $dbh-&gt;{RaiseWarn} which<b=
r>
cause that warnings reported by DBI drivers would behave like errors?<br>
<br>
For errors DBI has there $dbh-&gt;{PrintError} and $dbh-&gt;{RaiseError}<br=
>
attributes. First one is by default true and second one by default<br>
false. When PrintWarn is true, then all error from DBI driver are passed<br=
>
to perl&#39;s &quot;warn&quot; function and when RaiseError is true, then e=
rrors are<br>
passed to perl&#39;s &quot;die&quot; function. (Plus there is ability to re=
gister own<br>
error handler function)<br>
<br>
Currently DBI has only $dbh-&gt;{PrintWarn} attribute to control warnings.<=
br>
When is set to true (by default) all warnings from DBI driver are passed<br=
>
to perl&#39;s &quot;warn&quot; function.<br>
<br>
So I would propose to add $dbh-&gt;{RaiseWarn} attribute (off by default)<b=
r>
to behave like $dbh-&gt;{RaiseError}, but for warnings.<br>
<br>
I have implemented this attribute and patch is there:<br>
<a href=3D"https://github.com/perl5-dbi/dbi/pull/71/files" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/perl5-dbi/dbi/pull/71/files</a><br>
</blockquote></div>

--000000000000a0476a057fbda0ca--
0
grinnz
1/18/2019 4:01:31 PM
In my proposed implementation is HandleError called also for warnings
when RaiseWarn is enabled -- so for everything which is (later) going to
be passed to DBI's die. And based on return value of HandleError
callback, die/exception can be either silenced or re-throw like for DBI
errors.

Collecting all DBI warnings and storing them into special/custom log
looks like a good thing to do.

On Friday 18 January 2019 11:01:31 Dan Book wrote:
> As a side note, I have in the past thought a HandleWarn option may be
> useful, for instance to log warnings from the database or other custom
> behavior. It could also be used to throw exceptions.
> 
> -Dan
> 
> On Thu, Jan 17, 2019 at 4:03 AM <pali@cpan.org> wrote:
> 
> > Hello!
> >
> > What do you think about adding a new attribute $dbh->{RaiseWarn} which
> > cause that warnings reported by DBI drivers would behave like errors?
> >
> > For errors DBI has there $dbh->{PrintError} and $dbh->{RaiseError}
> > attributes. First one is by default true and second one by default
> > false. When PrintWarn is true, then all error from DBI driver are passed
> > to perl's "warn" function and when RaiseError is true, then errors are
> > passed to perl's "die" function. (Plus there is ability to register own
> > error handler function)
> >
> > 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 have implemented this attribute and patch is there:
> > https://github.com/perl5-dbi/dbi/pull/71/files
> >
0
pali
1/19/2019 11:34:35 AM
On Fri, Jan 18, 2019 at 10:47:41AM +0100, pali@cpan.org wrote:
> On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > On Thu, Jan 17, 2019 at 10:02:39AM +0100, pali@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.
0
Tim
1/20/2019 5:27:22 PM
On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> On Fri, Jan 18, 2019 at 10:47:41AM +0100, pali@cpan.org wrote:
> > On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, pali@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.
0
pali
1/21/2019 3:55:07 PM
On Monday 21 January 2019 16:55:07 pali@cpan.org wrote:
> On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> > On Fri, Jan 18, 2019 at 10:47:41AM +0100, pali@cpan.org wrote:
> > > On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, pali@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.
0
pali
4/12/2019 8:22:57 AM
Exactly, it is optional feature (turned off by default) which currently
is really missing and seems that it even cannot be "simulated" by
HandleSetErr.

On Thursday 17 January 2019 18:24:26 Dan Book wrote:
> While I'm a staunch opponent of fatal warnings in general, and I believe
> Pali has voiced concern with them as well, this is somewhat unrelated as it
> has nothing to do with the core warnings pragma and categories, and is
> simply an *option* to cause DBI to exhibit different behavior which it
> currently cannot. As such I think it's a fine idea.
> 
> -Dan
> 
> On Thu, Jan 17, 2019 at 6:20 PM Alexander Hartmaier <alex@hartmaier.priv.at>
> wrote:
> 
> > I didn‘t want to start a discussion about deprecation because I know the
> > opinion about that for most Perl 5 developers.
> >
> > But strictures and its use in Moo showed that exceptions from warnings
> > aren‘t welcome.
> > You can install a warn handler in your code without requiring any change.
> > Adding another option raises the number of combinations.
> >
> > As I don‘t see any benefit and no examples where given I‘m against it.
> >
> > > Am 17.01.2019 um 23:57 schrieb pali@cpan.org:
> > >
> > > Personally I do not like changing Print/Raise. It is documented,
> > > implementation seems to match documentation, it is without bugs and
> > > current behavior is usable.
> > >
> > > Anyway, back to my question about RaiseWarn. Do you think that it make
> > > sense to have it in DBI?
> > >
> > >> On Thursday 17 January 2019 11:02:51 Darren Duncan wrote:
> > >> Generally speaking, DBI is one of those things where backwards
> > compatibility
> > >> should be the highest concern after security.  There is a time and
> > place to
> > >> break compatibility, and this Print/Raise thing seems way too minor to
> > me
> > >> for that.  I support the version of this that is backwards-compatible
> > and
> > >> not the breaking version. -- Darren Duncan
> > >>
> > >>> On 2019-01-17 2:43 AM, pali@cpan.org wrote:
> > >>>> On Thursday 17 January 2019 11:06:22 Alexander Hartmaier wrote:
> > >>>> I'm aware of that, semantic versioning and major versions exist to
> > handle API breakage.
> > >>>
> > >>> Such thing is unsupported by CPAN clients. So we cannot use it.
> > >>>
> > >>> Anyway, this is question for Tim as DBI maintainer. But I guess he does
> > >>> not want to change API of DBI.
> > >>>
> > >>>> My question is how to detect if an exception is because of a warn or
> > a die when RaiseWarn is true.
> > >>>
> > >>> I guess you can use $dbh->err() method.
> > >>> See: https://metacpan.org/pod/DBI#err
> > >>>
> > >>> A driver may return 0 from err() to indicate a warning condition after
> > a
> > >>> method call. Similarly, a driver may return an empty string to indicate
> > >>> a 'success with information' condition. In both these cases the value
> > is
> > >>> false but not undef.
> > >>>
> > >>> Note that 'success with information' is not warning and therefore DBI's
> > >>> PrintWarn or RaiseWarn ignores them.
> > >>>
> > >>>> Best regards, Alex
> > >>>>
> > >>>>> On 2019-01-17 10:53, pali@cpan.org wrote:
> > >>>>> On Thursday 17 January 2019 10:23:25 Alexander Hartmaier wrote: > I
> > don't see the benefit, Print* should die This would break existing API of
> > DBI. Print just prints and Raise dies. This cannot be changed as there are
> > many applications which depends on this API. > and I'd personally would
> > release a major release and change the defaults as a breaking change:
> > PrintError false, RaiseError true. > Can you name a use case and how to
> > differ between an error and a warning at the error handling side? It is up
> > to the DBI driver or database server what would result in is a warning and
> > what in an error. > Best regards, Alex > > > On 2019-01-17 10:04,
> > pali@cpan.org wrote: > > Hello! What do you think about adding a new
> > attribute $dbh->{RaiseWarn} which cause that warnings reported by DBI
> > drivers would behave like errors? For errors DBI has there
> > $dbh->{PrintError} and $dbh->{RaiseError} attributes. First one is by
> > default true and second one by default false. When PrintWarn is true, the
> > >>>>  n all er
> > >>>>
> > >>>> ror from DBI driver are passed to perl's "warn" function and when
> > RaiseError is true, then errors are passed to perl's "die" function. (Plus
> > there is ability to register own error handler function) 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 have
> > implemented this attribute and patch is there:
> > https://github.com/perl5-dbi/dbi/pull/71/files
> > >>>>
> > >>>>
> > >>>
> > >>
> >
0
pali
4/12/2019 8:24:29 AM
On Fri, Apr 12, 2019 at 10:22:57AM +0200, pali@cpan.org wrote:
> On Monday 21 January 2019 16:55:07 pali@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?

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.
0
Tim
4/15/2019 3:21:30 PM
On Monday 15 April 2019 16:21:30 Tim Bunce wrote:
> On Fri, Apr 12, 2019 at 10:22:57AM +0200, pali@cpan.org wrote:
> > On Monday 21 January 2019 16:55:07 pali@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.
0
pali
4/15/2019 6:44:51 PM
Reply: