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 <a...@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 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 > > >>>> > > >>>> > > >>> > > >> > >
