On Fri, Apr 29, 2016 at 1:25 AM, Richard Hainsworth <rich...@1ptd.com>
wrote:
> throws-like { abc('excess') }, Exception, 'got the exception', message =>
> / excess recursion /;
I'm confused as to why you would expect this to work. The point of warn is
it is *not* an exception; an exception by definition aborts code execution,
while warn continues. As such, there is no exception and nothing you can
catch --- since if you could catch it, it would mean the original code
stopped executing and threw it instead.
I could imagine a design where the block where you used `warn` attached
some kind of extra value to whatever it eventually returns, but (a) it's a
horrid lot of extra complexity and slowdowns to handle such a thing, and
(b) you'd usually like to see the warning even if the block *doesn't*
return. If you want a side system of some kind that lets you treat *that*
case like an exception, then you're throwing fake exceptions to a whole
separate thread that sits there waiting for them and does something or
other --- again. lots of complexity for extremely dubious gain, and if you
then decide that since you got your warnings-are-exceptions you should now
get the full suite of things you could do with an exception... you now have
that warnings must stop until the side thread tells them what to do, or
else make warnings into full exceptions with some kind of resume capability
that is turned on by default. But this isn't an actual warning and now
people will ask why we don't have warnings, just resumable exceptions....
In short: exceptions are not warnings, not practically and not
conceptually; they are a completely different thing entirely. No amount of
scaffolding will turn an apple into a horse. Use Test::Output.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
