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.

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

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 :)