RaiseWarn attribute for DBI

2019-01-17 Thread pali
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread Darren Duncan
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread Alexander Hartmaier
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread Dan Book
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread Alexander Hartmaier
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, p...@cpan.org wrote: > On Thursday 17 January 2019 10:23:25

Re: RaiseWarn attribute for DBI

2019-01-17 Thread Alexander Hartmaier
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread pali
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread pali
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

Re: RaiseWarn attribute for DBI

2019-01-17 Thread pali
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