You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whenever the driver can't require a specific driver subclass, it sets "$@" to report this.
"$@" then leaks out, which creates a pitfall for any subsequent client code that is looking for errors.
in pre-0.42 DBIx::Connector, subsequent operations would usually clear the "$@" variable "accidentally" - but since 0.42, "$@" has been localised inside the try* subroutine's new TRY block which prevents them from accidentally unbuggering the global one.
I would recommend having the driver constructor unset $@ before returning, as this "error" resulting from falling back to the default driver is not something that calling code ever really needs to see (and if it needs to know its on the default driver, there are better ways to find out).
The text was updated successfully, but these errors were encountered:
Whenever the driver can't require a specific driver subclass, it sets "$@" to report this.
"$@" then leaks out, which creates a pitfall for any subsequent client code that is looking for errors.
in pre-0.42 DBIx::Connector, subsequent operations would usually clear the "$@" variable "accidentally" - but since 0.42, "$@" has been localised inside the try* subroutine's new TRY block which prevents them from accidentally unbuggering the global one.
I would recommend having the driver constructor unset $@ before returning, as this "error" resulting from falling back to the default driver is not something that calling code ever really needs to see (and if it needs to know its on the default driver, there are better ways to find out).
The text was updated successfully, but these errors were encountered: