Front page | perl.perl5.porters |
Postings from July 2023
Thread Previous
|
Thread Next
On Mon, Jul 17, 2023 at 5:16â¯PM demerphq <demerphq@gmail.com> wrote:
>
> 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.
>
Far beyond the scope of what I have bandwidth for right now, but for one
large client, I implemented a core exception mechanism for their ORM. What
surprised me is every place the code would die, it would catch the error.
If it was an object, it would die with the object. If it was a plain
string, it would promote it to a "generic" exception object. All objects
had overloaded stringification to ensure the previous code worked as
expected, even when we hit messes like this:
try {
$customer->update(@args);
}
catch ($error) {
if ( $error =~ /bad version number/ ) {
...
}
}
In short, *every* exception was an object. Honestly, given the
multi-million line size of their code base, I'm surprised it worked so
seamlessly, with old code working exactly as expected, but new code being
able to query the object, even when it used to be a plain die.
I imagine having die return an object with overloaded stringification might
not scale for the darkpan. That's mainly because I know there are going to
be edge cases I haven't thought about, but there's a potential path forward.
Best,
Ovid
--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Thread Previous
|
Thread Next