Cut back differs in that it does not run the current object to completion. I agree that it seems better to preserve any existing error status when cutting back, to prevent spurious execution such as what you saw.
I am loath to make such changes without knowing how much users depend on current behavior. Henry Rich On Thu, Jun 16, 2022, 6:57 PM Raul Miller <[email protected]> wrote: > On Thu, Jun 16, 2022 at 9:32 AM Henry Rich <[email protected]> wrote: > > The debugger gets control at the end of a completed sentence, which may > > complete with error. Sentences in calling functions are in mid-execution. > > There is no way to resume a sentence in execution except by returning to > it > > to let it finish. > > We are talking about this mechanism, yes? > > 13!:19 y Cut Back. Cut back one stack level, stopping at the line at > the next stack level. > > I see two possibilities for the implementation here: > > (a) "Cut Back" throws a specialized error (something like a Value > Error), preventing further execution of the calling statement, or > > (b) "Cut Back" returns immediately and uses a > breakpoint-like-mechanism to regain control in the calling statement. > > But option (b) corresponds to: > . > [x] 13!:22 y Step Out. Run the current object to completion, starting > with the current line (or line x if specified), stopping at the next > line. > > So, ... it doesn't really make sense to me that we'd have 13!:19 if it > was meant to behave like 13!:22. > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
