At 11:02 PM 8/17/00 -0600, Tony Olekshy wrote:
> > Note: I used to favor $_[0] for the exception, but I'm being
> > won over to $@. As long as it doesn't cause problems with
> > external interfaces. Might mention the $_[0] idea in a
> > footnote.
>
>Done.
Um, see last message. There's a lot to be said for passing the whole
exception stack in @_.
> > > @DB::ISA = 'Exception';
> >
> > I think you want to s/Error/Exception/ above. Then the rule is
> > simpler. Require all exceptions to be subclasses of 'Exception'
> > for clarity.
>
>If I did it that way, then to create an exception error class
>derived from Exception, I'd have to call it Exception::Error.
>This would mean testing for Exception::Error::IO::File::Open.
Why not Exception::IO::File::Open? Why do you want this hierarchy called
Error?
>We write a lot of simple throws, most of which would look like
>this with the new mechanism as proposed so far:
>
> throw MyDB "ABC.1234: Some message about what went wrong.";
>
>Without the techniques and hooks I've described in 88v2d2, I'd
>have to write the following, which has a much lower signal to
>noise ratio.
>
> throw Exception::MyDB tag => "ABC.1234",
> message => "Some message about what went wrong.";
Disagree. Firstly, your simple case doesn't have the word Exception in it
anywhere, which I think is a big visual marker; MyDB is a subclass of it,
right? Secondly, I think your tag/message splitting idea is fragile; what
happens when some application doesn't want to use tags but does want to
throw a message like "yikes: buffer overflow"?
Can't heavy users like yourself define some convenience function of your
own for getting the short version? Can we use positional arguments as a
shortcut? I guess that means the attributes need to be -tag and
-message. But at least then you could do
throw Exception::MyDB "ABC.1234", "Some message about what went wrong"
or even the cooler
throw Exception::MyDB "ABC.1234" => "Some message about what went
wrong"
>Even though I want non-local flow-control to stand out with new
>keywords, I don't what it to obfuscate and overwhelm the source
>code for the algorithms that use it.
>
>And, I really want to encourage people to put an annotating message
>on *all* the exceptions they raise; I don't want to make it harder by
>requiring the minimal canonical throw form to always have to contain
>the message => tokens.
Um, depends how much you use them. Someone who just uses the odd exception
here and there or gets a piece of code from someone else shouldn't have to
scratch their head to figure out an odd syntax.
>Done. But one can still say C<throw Exception;> so the issues
>don't completely go away.
Error: insufficient arguments to throw.
> > Hmm... what is the benefit of being able to throw objects that
> > aren't exceptions?
>
>The question is, what happens when someone throws an object
>that isn't an Exception?
Run-time error. Almost certainly they threw the wrong object and should
find out immediately.
> > I know I was pushing for this, but Ive seen the light that in
> > fact caller() should be doing this for us. Can you see any
> > reason that won't do?
>
>Here I don't understand. How can caller give us the raise-time
>call stack at catch time (at the latter time, it can only give
>us the catch-time call stack).
Sorry, I was confused. You're right.
>Hmm, I'm assuming open throws
>error exceptions in this example, perhaps I should make that
>more clear, so I changed the draft to read:
>
> if (open(*F, ">foo")) { try { ... } finally { close F; } }
But everyone will wonder why you aren't trapping the open, since it's the
most likely statement in there to throw an exception and we've been saying
all along that it should. How can the reader tell that this open won't
throw an exception?
> > See my earlier comments about all linked blocks sharing the
> > same lexical scope, btw.
>
>I'd rather not introduce that complexity into the RFC. It's
>already hard enough to keep track of lexical scope in nested
>closures; I don't want to add nested combinations of trys
>(possibly containing closures) into the mix. I've added an
>ISSUE to this effect to the RFC.
It's pretty simple; you're just saying that the blocks share the same
lexical scope the same way that apparently disconnected while and continue
blocks do.
>Thanks. How much would you pay for this--but wait, there's more.
>Here's a quote from the Encyclopaedia of Software Engineering
>that's going into 88v2d2 (check there for the full reference).
>
> Among the features offered by programming languages to
> support exception handling are the following.
>
> 1. The ability to distinguish the normal control flow from
> the exception handling flow to make the structure of the
> program clear.
I think it would be best to supply a reference. This is a mammoth RFC
already and it will be decided on by people who very well know what
exception handling is; their reading time is at a premium.
--
Peter Scott
Pacific Systems Design Technologies
