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 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
