Skip Menu |

This queue is for tickets about the UNIVERSAL-can CPAN distribution.

Report information
The Basics
Id: 17043
Status: resolved
Priority: 0/
Queue: UNIVERSAL-can

People
Owner: Nobody in particular
Requestors: adamk [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.02
Fixed in: (no value)



Subject: Don't recommend eval-wrapping
OK, starting to get a bit more pedantic now :) I went through the same process with Class::Autouse, so now I get to inflict the pain on to you some more. You shouldn't recommend eval-wrapping of ->can calls. Because ->can can be implemented by modules in custom code, that custom code (unlike the actualy UNIVERSAL::can function) can throw die/exceptions). Those errors need to ACTUALLY die. By eval-wrapping a ->can call, people are going to effectively ignore the errors thrown by ->can methods, and thus trigger a falsely-correct false result from the ->can call. This could easily result in either totally incorrect errors being called, or incorrect behaviour. Any there's nothing you can really add to UNIVERSAL::can (the module) to prevent it (I think...) because it never makes it to your code (it hits the custom ->can method before yours)... So you can't recommend eval-wrapping. You have to a) ONLY recommend (Params::Util::blessed($_[0]) and $_[0]->can('foo')) type tests or b) Wait for me to add an importable _CAN function to Params::Util.
hmm... or c) YOU add an importable _CAN function. :)
On Fri Jan 13 03:32:34 2006, ADAMK wrote: Show quoted text
> hmm... or c) YOU add an importable _CAN function. :)
ok, except that would probably impose 5.6 on everybody, which is bad. So maybe I do add _CAN to Params::Util, which is meant to be 5.005.
Subject: Re: [rt.cpan.org #17043] Don't recommend eval-wrapping
Date: Fri, 13 Jan 2006 01:31:45 -0800
To: bug-UNIVERSAL-can [...] rt.cpan.org
From: chromatic <chromatic [...] wgz.org>
On Friday 13 January 2006 00:31, via RT wrote: Show quoted text
> You shouldn't recommend eval-wrapping of ->can calls. > > Because ->can can be implemented by modules in custom code, that custom > code (unlike the actualy UNIVERSAL::can function) can throw > die/exceptions). > > Those errors need to ACTUALLY die.
UNIVERSAL::can() doesn't throw exceptions, so there's a substitutability argument against child implementations throwing exceptions -- at least without documenting them. On the other hand, if they do document them, the eval block ought only to catch "Can't call method..." errors, rethrowing everything else. That seems like the most appropriate approach. Now I'm wishing for some sort of typed exceptions... gah, and a new patch to UNIVERSAL.pm. -- c
I added a warning in the documentation about checking the exact exception caught in this case in 1.14.