It looks like a lot more code, but so does the part() example in Exegesis 6. I still liked the flexibility it gave me.eval { $self->find($foo); }; if ($@) { if ($@->isa('Signal::Search') { if ($@->isa('Signal::Search::Found')) { print "found"; } else { print "Not found"; } } else # These are (presumably) error conditions ... { # Handle error here. } }
Now, the system I seem to be proposing here involves using try-catch (or eval-$@) syntax throughout the entire application, including all callers. To me, this isn't something you can just implement in one part, but not the other. I would completely eschew return for status codes and use it only when there is something to actually return, other than true or false. (Speaking of truth/falsehood, you could rename the signals to Signal::True and Signal::False and collapse the number of signals you're working with. But, I prefer to have all the signals explicitly named.)
As for the worry that you're propagating a bunch of classes, you could have each class define the signals it happens to the only user of, so that the useing of the class auto-uses the signals for that class. TMTOWDI.
------
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
In reply to Re: Re^10: Learning how to use the Error module by example
by dragonchild
in thread Learning how to use the Error module by example
by cleverett
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |