At 07:07 AM 8/12/00 -0600, 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
I've redirected to perl6-language-flow. They're supposed to enjoy being
bothered with it :-)
>, 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 and make sure the ids don't collide with anything else you
get? Number ranges for user space (e.g., negative numbers) are all well
and good, but eventually you'll have two or more separate things both
living in user space but constructed independently.
I was attempting to carry RFC 85 to its logical extension, but perhaps I
stretched it too far.
I think it's not as bad as you imply though. 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.
> > Line number exception was thrown at.
> > File exception was thrown in.
>
>Should this be line thrown at or line constructed at? Does anyone
>care?
There is an issue of how far up the call stack you should go. If I write
main.pl:
1 try {
2 foo($obj);
3 };
4 sub foo {
5 $_[0]->bar();
6 }
Foo.pm:
100 sub bar {
101 pling(shift);
102 }
103 sub pling {
104 throw Exception::Baz unless blech(shift);
should the (file, line) be: (main.pl, 2), or (Foo.pm, 101) or (Foo.pm,
104)? Clearly if you wrote Foo.pm you'd like the last one, and if you
didn't, you'd like the first one. Well, probably you'd want all of
them. 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.
> > Stringifying the object itself will yield the C<message> attribute.
>
>Or perhaps a formatted combination of a subset of the attributes,
>as in RFC 96?
Or the confess() I just suggested above, yes.
--
Peter Scott
Pacific Systems Design Technologies
