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

Re: RaiseWarn attribute for DBI

Thread Previous
From:
pali
Date:
April 12, 2019 08:24
Subject:
Re: RaiseWarn attribute for DBI
Message ID:
20190412082429.kofbqmyh6ffrfbd2@pali
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
> > >>>>
> > >>>>
> > >>>
> > >>
> >

Thread Previous


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