> > > 3) Implement a new LightException (or similar name) with no args in > getTrace(). > > + or 4) Deferred backtrace mechanism: > > 1. Does not compute the backtrace when the exception is created. > 2. The backtrace is fully computed only if the exception is caught using a > catch block or by a global handler when reaching the bottom of the stack. > 3. The backtrace may not be computed at all if the exception is caught for > suppression (possibly requiring separate syntax). > > There is a technical problem here. > When a user saves an exception object somewhere and later tries to > retrieve the trace. > If a solution to this can be found, then no changes would be needed on the > UserLand side at all. ... >
Clarification. It is possible to link the lifetime of an exception to the lifetime of the frame in which the exception was caught or thrown. If the frame is destroyed but the exception is not, then the backtrace must be generated. If the exception is destroyed first, backtrace generation is not needed. The overall algorithm is as follows: 1. An exception is created. The trace is not generated. The exception is linked to the frame where it was thrown. 2. If the exception is thrown, the stack unwinding mode is activated. 3. If the exception is not thrown but the frame is being destroyed, a full backtrace is generated before the frame is destroyed. 4. In stack unwinding mode, the backtrace is built step by step until the exception is handled in a catch block. 5. If the frame is destroyed while the exception still exists, a full backtrace is generated; otherwise, nothing happens.
