Re: Towards a reasonable unwinding flow-control semantics.

>>>>> "PS" == Peter Scott <[email protected]> writes:

PS> At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> >>>>> "PS" == Peter Scott <[email protected]> writes:
>> 
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
>> 
>> Err, if there isn't one. Don't throw the exception. Stop processing but
>> don't throw. You are imposing a style on your caller.

PS> ???  I don't get this at all.

Consider a module A uses try all over the place. Module B uses procedural
call, and accepts callbacks from A.

The callbacks from A raise/throw around B. B's author would like to
be able to do some cleanup, restore invariants, whatever, after a
callback fails. By allowing the caller to determine how the errors
are delivered we are allowing the author more freedom in his design.

So all he would need to add would be a lexical pragma, use exception 'return'

>> A message would be appropriate (ala, die or warn)
>> 
>> Also a use (within main or if it can work lexically) that would mean
>> die_if_exception_thrown. Would treat the main routine as if it were
>> wrapped in a try block that doesn't catch any exceptions.

PS> RFC 63 already states this.  Uncaught exceptions at the outermost
PS> level are dies.  (And there is a very close relationship between
PS> die and throw.)

But I don't want that. Why? Throws are error returns not death.

A module author should _never_ invoke die. How does the module author
know what the caller wants to be done. 

I just don't want to be forced into scattering lots of little try{}
just to get back to my error return style of coding.

<chaim>
-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
[email protected]				               +1-718-236-0183