• BCS (44/44) Mar 17 2006 The proposal:
• Sean Kelly (8/18) Mar 17 2006 This was discussed back when exception handling was being designed for
• Chris Miller (2/8) Mar 19 2006 "drop" seems to fit in nicely :)

BCS <BCS_member pathlink.com> writes:

The proposal:

   Provide a mechanism that allows for the in-place handling of exceptional 
cases. Rather than abandon the entire function call, when this mechanism is 
encountered, the runtime environment searches back through the call stack (much 
like with a normal throw) until it finds a handler and executes it and then 
returns execution to the place that the exception was raised. This could be
used 
in cases where the exception case might be an error but not always or in cases 
where the problem can be fixed.

pros:
   Lightweight, no stack unwinding, could uses a global function ptr table.
   Allows for cheaper fix to fixable problems.
cons:
   Might be prone to abuse and or faulty use.
   Needs care that "fix" doesn't corrupt things.

   As I couldn't come up with any good keywords to use, I will give my examples 
with some somewhat humors choices. An exception handler for this type of 
exception will be called a "hammer", to raise one of these fixable exceptions 
use the keyword "nail".
   ("If the only tool you have is a hammer, every problem looks like a nail).


------------------

   // find the sample mean
   real SampleMean(SampleSet s)
   {
     if(0 == s.Number)                   // is there any data?
     {
       nail new SampleSet.NoSamples(s);  // try to fix the error
       assert(0 != s.Number);            // make shure it's fixed
     }

     return s.Sum/s.Number               // compute
   }


   ...

   try
   {
     writef("the mean is: ", SampleMean(i));  // try to print the mean
   }
   hammer(SampleSet.NoSamples e)              // if there is no data
   {
     e.Data.UpdateDataSet();                  // try to get more data
     if(0 == a.Data.Number)                   // check if we did
       throw Excption("Sorry, no data");      // if not, error
   }

   ...


------------------
Just a thought, if this waits till >1.0, oh well.

Sean Kelly <sean f4.ca> writes:

BCS wrote:
 The proposal:
 
   Provide a mechanism that allows for the in-place handling of 
 exceptional cases. Rather than abandon the entire function call, when 
 this mechanism is encountered, the runtime environment searches back 
 through the call stack (much like with a normal throw) until it finds a 
 handler and executes it and then returns execution to the place that the 
 exception was raised. This could be used in cases where the exception 
 case might be an error but not always or in cases where the problem can 
 be fixed.

This was discussed back when exception handling was being designed for 
C++ and the idea was ultimately rejected as problematic.  I don't have 
any references regarding why offhand, but I remember it being mentioned 
in "The Design and Evolution of C++."  There's nothing stopping an 
application programmer from doing this now, however.  In fact, I do call 
error routines from time to time, instead of simply throwing an exception.


Sean

"Chris Miller" <chris dprogramming.com> writes:

On Fri, 17 Mar 2006 20:04:08 -0500, BCS <BCS_member pathlink.com> wrote:

    As I couldn't come up with any good keywords to use, I will give my  
 examples with some somewhat humors choices. An exception handler for  
 this type of exception will be called a "hammer", to raise one of these  
 fixable exceptions use the keyword "nail".
    ("If the only tool you have is a hammer, every problem looks like a  
 nail).

"drop" seems to fit in nicely :)