Peter Scott wrote: > > Tony Olekshy wrote: > > > > Peter Scott wrote, in RFC 80 (v2): > > > > > > =item id > > > > > > Unique numeric identifier, assigned by perl developers. > > > > I'm loath to bother everyone with this but to me the id of an > > object should be unique to each *instance* of the class. If we had > > > > my $e = Exception->New(id => "ABC.1234"); > > my $f = Exception->New(id => "ABC.1234"); > > > > then $e and $f would have the same id, but be different objects. > > Yes, the implicit registry bothers me too - not for the core: I > figure the perl developers can manage a little enumeration class - > but for external stuff. CPAN could conceivably work since they > already have a registry for the naming hierarchy, but what about > when you want to write an in-house thingy [...] Sorry I wasn't more clear on this. I'm just saying that "id" is a bad name for this "labelling" field; if it's called "id" then it should be guaranteed, by Perl, to be a unique identifier. So I propose calling it "tag" instead. > We could disambiguate id tags by checking the exception class > name, since it's reasonable to assume that anything throwing > an exception in a particular class will coordinate ids with > everything else doing the same. I agree, as long as we have a way to select exception handling based on "$class:$tag" or something like that. I'm working on that in RFC 88 v2. > > > Line number exception was thrown at. File exception was > > > thrown in. > > > > Should this be line thrown at or line constructed at? Does > > anyone care? > Hmm - what if we made line() and file() return arrays? Then we'd > also like uncaught exceptions that result in program death to at > least have the option of a confess() backtrace, and the data would > be in the object. I think the exception constructor should use the conctructor's invocation point, and the throw operation should independently track the location of the throw. I keep getting lead back the concept of the exception unwinding stack, a natural place to keep track of the throws. I'll try to do a better job of making said stack simpler in RFC 88 v2. One possibility, if we have a base exception class, is to use a "link" field to point to the previous exception when a new exception is raised while processing an existent exception. Then, all exception selection can be done on the basis of the methods (including ivar accessor methods) of the exception object. Yours, &c, Tony Olekshy
