Front page | perl.perl5.porters |
Postings from July 2023
Thread Previous
|
Thread Next
On Wed, 8 Jun 2022 at 13:13, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:
> On Wed, 8 Jun 2022 09:04:23 +0200
> Alexander Hartmaier <alex.hartmaier@gmail.com> wrote:
>
> > I really wonder that I've never read a blog post or mailing list
> > thread about the lack in exception handling in Perl 5. It's my
> > biggest pain point with Perl 5 and I'd love to help to improve the
> > situation!
>
> Well-volunteered :)
>
> If you want to assist, probably the first main question that needs
> answering is working out what the programmer-visible API on these
> things ought to be.
>
> While it is initially tempting to suggest that `catch` would expose
> core-thrown exceptions as objects, there is already a problem here. In
> the past 20-odd years, the $@ variable (and more recently catch) have
> always exposed core-thrown exceptions as plain strings;
FWIW, this partially interacts with a bug which I fixed in 5.38. I say
partially because the core does indeed put a string in $@, but it combined
with a bug in how eval was handled that $SIG{__DIE__} was not executed for
compile errors consistently such that code that expected to upgrade those
string errors into exception objects would not execute. IN 5.38 i fixed
eval so that if it dies during compilation it will always call
$SIG{__DIE__} and thus any handlers intended to upgrade $@ to an object
will now fire consistently.
anything that
> appears as an object must have been some user-thrown object:
>
> use builtin 'blessed';
>
> try {
> maybe_call_a_func();
> }
> catch ($e) {
> if(blessed $e) {
> warn "Caught a user-defined exception of type " . (blessed $e);
> }
> else {
> warn "Caught a plain stringy exception";
> }
> }
>
> What should we do here?
>
> 1) Throw objects of some core-defined type, so `ref` and `blessed` are
> now true on these things, meaning they can be distinguished -
> including by some sort of `isa` test as might someday be added to
> `catch`, but thus breaking all existing code which inspects $@ or
> $e.
>
> 2) Throw plain strings that have some other, new way to query some
> hidden "error type" information stored within them. Maybe lets
> invent some new `builtin` funcs and imagine a hypothetical future
>
The problem with throwing objects is that there is no standard way to allow
them to be modified by the calling code to add data to the error. With
strings it is obvious how you can change them, but unfortunately you change
the context the error was thrown from.
For example in
eval $code or die "While executing $code: $@";
the error is extended, but its source changes. The error would be reported
as coming from the line where the eval was executed, not where the
exception actually occurred.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next