develooper Front page | perl.dbi.dev | Postings from January 2019

Re: RaiseWarn attribute for DBI

Thread Previous | Thread Next
From:
Dan Book
Date:
January 17, 2019 23:24
Subject:
Re: RaiseWarn attribute for DBI
Message ID:
CABMkAVXTD4APEumCfg9ZABE-hRK+p4CM1o=dsLP=aECD2yHuVA@mail.gmail.com
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
> >>>>
> >>>>
> >>>
> >>
>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About