# [RFC] try ... finally ... entry enhancements?

Richard Godard (janus@cam.org)
Mon, 14 Jul 1997 17:42:11 -0400

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    At 0:54 -0400 7/11/97, Rich Connamacher wrote:
    >I don't understand what you mean.
    >
    >If you want to execute code that will run if the try statement doesn't
    >raise an error or return?  That's simple, just make it the last try
    >statement.
    >
    >Finally statements are just pieces of code that are run nomatter what,
    >though they can be snuck past with a timeout or kill_task(task_id()).  I
    >don't know what you mean in making finally statements "smart".  What
    >exactly are you trying to accomplish?  Could you please explain it?

    Sure, let me to it with an example... right now I'm implementing trace
    in-db that way; traced verb code looks like:

    __trace_step_out_args__ = $trace_utils:step_in(args);
    try

      <statements>

    finally
      $trace_utils:step_out(@__trace_step_out_args__);
    endtry

    What I would like if that when the finally is called, I would like to know
    what's going on... it is returning a value? which one? is it raising an
    error? what's the trace? or is it just continuing execution...

    If I could do:

    __trace_step_out_args__ = $trace_utils:step_in(args);
    try

      <statements>

    finally exit_info
      $trace_utils:step_out(@__trace_step_out_args__, exit_info);
    endtry

    Where exit_info would be a variable holding the info regarding what's the
    state of the code execution when it hit the finaly statements...

    >Also, in a language statement, it's not neccessary to follow a strict LIST
    >format.  I'm sure a more intuitive format could be found.

    Not really... need to be a list since a bunch of values are needed...

    I hope this make things clearer...

    Richard

    P.S. for those who wonder, the trace system as I wrote it right now is an
    overhead of 20 ticks per verb call... innaceptable for a production MOO,
    but for a developement one when you are using an unfamiliar core, it helps
    :)
    Heh if it was possible to have accurate 'time' info about the number of
    ticks/seconds elapsed it could even be used to do profiling with a very
    minor hack (HINT HINT! :)