Front page | perl.perl5.porters |
Postings from June 2022
> On Jun 8, 2022, at 22:24, Dan Book <grinnz@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 10:17 PM Karen Etheridge <perl@froods.org> wrote:
> On Wed, Jun 8, 2022 at 12:56 PM Dan Book <grinnz@gmail.com> wrote:
> Whenever $@ is populated, the relevant logic would check to see if the active feature set dictates putting the object or the string into $@.
>
> This is exactly the problem. The lexical feature would have an effect on the exact problematic code we are discussing (which is by the way not "esoteric" in any useful sense of the word, we simply cannot break it), which is not in the scope of the feature.
>
> If I'm following correctly, we want the *caller* of the exception-throwing code to decide whether it wants an error string or an error object. Therefore, make $@ into a dualvar-like construct that holds both pieces of information, and use the context of the caller to decide which form is used in an expression containing $@.
>
> That's roughly LeoNerd's extended error type proposal from the start of this thread.
Sort of.
LeoNerd proposes (as I understand it) some new error-metadata to be stored with the error string. I, at least, envision something simpler:
------------
try {
9/0;
}
catch ($e) {
$e isa Error::Perl::DivByZero; # truthy
say $e; # same string as ever
}
eval { 9/0 };
blessed $@; # falsy
say $e; # same string as ever
------------
… where Error::Perl::DivByZero is just a string-overloaded class the likes of which many of us have likely seen.
eval’s behaviour wouldn’t change, so existing code that assumes only user exceptions are blessed would be unaffected. Since try/catch is still experimental, any breakage from the change in that context will be “allowed” breakage.
-FG
Thread Previous
|
Thread Next