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 p...@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, p...@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, p...@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, >>>>> p...@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 >>>> >>>> >>> >>
