On Monday 15 April 2019 16:21:30 Tim Bunce wrote:
> On Fri, Apr 12, 2019 at 10:22:57AM +0200, p...@cpan.org wrote:
> > On Monday 21 January 2019 16:55:07 p...@cpan.org wrote:
> > > On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> > > >
> > > > Couldn't HandleSetErr be used for this?
> > > >
On Fri, Apr 12, 2019 at 10:22:57AM +0200, p...@cpan.org wrote:
> On Monday 21 January 2019 16:55:07 p...@cpan.org wrote:
> > On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> > >
> > > Couldn't HandleSetErr be used for this?
> > >
> > > Quoting the docs at
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
On Monday 21 January 2019 16:55:07 p...@cpan.org wrote:
> On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> > On Fri, Jan 18, 2019 at 10:47:41AM +0100, p...@cpan.org wrote:
> > > On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org
On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> On Fri, Jan 18, 2019 at 10:47:41AM +0100, p...@cpan.org wrote:
> > On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote:
> > > >
> > > > Currently DBI has only
On Fri, Jan 18, 2019 at 10:47:41AM +0100, p...@cpan.org wrote:
> On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote:
> > >
> > > Currently DBI has only $dbh->{PrintWarn} attribute to control warnings.
> > > When is set to true (by
In my proposed implementation is HandleError called also for warnings
when RaiseWarn is enabled -- so for everything which is (later) going to
be passed to DBI's die. And based on return value of HandleError
callback, die/exception can be either silenced or re-throw like for DBI
errors.
As a side note, I have in the past thought a HandleWarn option may be
useful, for instance to log warnings from the database or other custom
behavior. It could also be used to throw exceptions.
-Dan
On Thu, Jan 17, 2019 at 4:03 AM wrote:
> Hello!
>
> What do you think about adding a new
On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote:
> >
> > 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"
On Thu, Jan 17, 2019 at 10:02:39AM +0100, p...@cpan.org wrote:
>
> 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}
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
