@leftibot does this PR provide the value that I thought it would when I asked for it?

Partially. The PR delivers the structural foundation from issue #63 — eval_error now derives from std::nested_exception, and Boxed_Value exceptions thrown from scripts are wrapped so users can recover the original via rethrow_nested() / nested_ptr(). That's the core ask and it works.

However, issue #63 specifically asked to "ax the exception_specification from the eval function and move it to an overload of nested_exception::rethrow for auto unboxing of Boxed_Value objects that were captured." This PR doesn't do that — the Exception_Handler parameter remains on all eval() overloads, and there's no auto-unboxing rethrow method on eval_error.

There are also a couple of concerns with the current implementation:

1. Inconsistent wrapping when Exception_Handler is used. In chaiscript_engine.hpp:694-698, the handler's handle() may throw a typed exception (that's its entire purpose — unboxing the Boxed_Value into e.g. std::runtime_error). If it succeeds, that typed exception escapes unwrapped. If it doesn't match, the new eval_error is thrown with nesting. So depending on whether the handler matches, callers get completely different exception hierarchies.

2. Lost call stack. The new throw path uses eval_error(const std::string&) which doesn't populate call_stack, start_position, or filename. Existing eval_error construction elsewhere in the engine populates these fields — the wrapping path should too, since the whole point of issue Derive eval_exception from std::nested_exception and wrap all thrown exceptions with eval_exception #63 is better diagnostics ("allow for a stack trace to be generated").

3. Missing the architectural payoff. The real value of this change — as described in issue Derive eval_exception from std::nested_exception and wrap all thrown exceptions with eval_exception #63 — is simplifying the caller's exception handling. Today users must pass exception_specification<...>() to eval() and write type-specific catch blocks. The intended design would let them catch eval_error, then call something like ee.rethrow_as<std::runtime_error, int, double>() to get auto-unboxed typed exceptions. Without that, the nesting is just an extra layer of indirection for the same use case.

Bottom line: The derivation from std::nested_exception is correct and the tests demonstrate it works, but the PR stops short of the API simplification that was the motivating value of issue #63.

@leftibot update this PR so that we get the full payoff for it

Addressed review feedback from @lefticus. New commits:

97e8b0a2 Address review: add rethrow_typed and boxed_value accessors to eval_error

@leftibot your tests are all failing. Correct the issues and document the payoff we get from this change.

Addressed review feedback from @lefticus. New commits:

75430431 Merge develop and fix test conflicts for eval_error wrapping
5b9c5e00 Address review: fix test failures and restore tests from develop with updated expectations
e61be765 Fix #601: Allow operator functions to accept any type with an add() method (#686)
d4c5bdb3 Fix #61: Comprehensive exception test suite and fix for silently swallowed exceptions (#681)

@leftibot does this now give us the payoff we were hoping for?

Getting closer, but there are still two gaps between what's here and the full payoff from issue #63.

What works well

The core API shape is right: eval_error derives from std::nested_exception, has_boxed_value() / boxed_value() give direct access to the wrapped value, and rethrow_typed<Types...>(engine) provides the auto-unboxing that replaces the need for exception_specification. The tests cover all the new surface area. eval_file() delegates to eval() so it gets wrapping for free.

Gap 1: No call stack on wrapped exceptions

The new constructor at chaiscript_common.hpp:342-345:

eval_error(const std::string &t_why, Boxed_Value t_bv) noexcept
    : std::runtime_error("Error: \"" + t_why + "\" ")
    , reason(t_why)
    , m_boxed_value(std::move(t_bv)) {
}

…doesn't populate call_stack, start_position, or filename. So when a user catches the wrapped eval_error and calls pretty_print(), they get:

Error: "Exception thrown during evaluation"

No file, no line number, no call stack. The entire motivation of issue #63 was "allow for a stack trace to be generated" for script-thrown exceptions. Without that, wrapping in eval_error is just adding a layer of indirection. The wrapping site in chaiscript_engine.hpp has t_filename available — it should be threaded through, and ideally the call stack should be captured from the dispatch engine's state at the throw point.

Gap 2: Inconsistent exception hierarchy when Exception_Handler is used

In chaiscript_engine.hpp:701-705 (on the PR branch):

} catch (Boxed_Value &bv) {
    if (t_handler) {
        t_handler->handle(bv, m_engine);  // throws typed exception on match
    }
    throw exception::eval_error("Exception thrown during evaluation", bv);
}

If t_handler->handle() matches, it throws a raw typed exception (e.g. std::runtime_error) that escapes unwrapped — the caller gets a typed exception, not an eval_error. If it doesn't match, the caller gets an eval_error. So the exception type the caller sees depends on whether the handler matched, which is fragile.

This is arguably backward-compatible (existing exception_specification users expect the typed exception), but it undercuts the "single catch point" promise. If we want to preserve backward compatibility here, at minimum it should be documented that exception_specification bypasses the new wrapping.

Bottom line

The API surface (has_boxed_value, boxed_value, rethrow_typed) delivers the ergonomic payoff for callers. But the missing call stack means we're not yet getting the diagnostic payoff — which was the original reason for issue #63.

@leftibot keep refining this feature to add the gaps you have mentioned.

Addressed review feedback from @lefticus. New commits:

5cebd2cd Address review: add call stack and filename to wrapped script exceptions

@leftibot where is this branch now? Does it get the payoffs from the better handling of the exception types? Does it address #515 ?

Where the branch is

• Branch: fix/issue-63-derive-eval-exception-from-std-nested-ex on leftibot/ChaiScript (PR Fix #63: Derive eval_exception from std::nested_exception and wrap all thrown exceptions with eval_exception #682, still open).
• Status: Behind develop and marked DIRTY / CONFLICTING. Since the last touch on 2026-04-15 (5cebd2cd), develop has taken ~10 merges (Fix #61: Thoroughly test throwing of exceptions from various contexts #681, Fix #601: Passing chaiscript::ChaiScript reference to add_class for enumerations #686, Fix #678: Fix WASM build to include support for exceptions #689, Fix #628: Grammar railroad diagram #673, Fix #552: Feature-request: nested namespaces #675, Fix #19: Add enum support #679, Fix #677: Add strong typedefs #680, Fix #116: Need using load_file, a callback is needed to provide special implementation. #683, Fix #690: Apply clang-format consistently with CI #691, Fix #374: std::vector of std::vectors ChaiScript conversion failure #692). A local test merge shows a real conflict in unittests/compiled_tests.cpp (the rest auto-merge). The PR will need a merge/rebase before it can land.
• CI on the last push: all 22 checks green except Linux GCC ASAN+UBSAN Release, which failed. Worth re-running after the develop merge to confirm whether it's flake or a real issue.

Does it get the payoffs?

Yes — the structural and ergonomic payoffs are all in place now. The 5cebd2cd commit closed the gaps I flagged in the earlier review:

• Call stack accumulation for script throws. AST_Node_Impl::eval() at include/chaiscript/language/chaiscript_eval.hpp:138-150 now catches Boxed_Value, wraps it in eval_error, and pushes each AST node onto call_stack as the exception propagates. Script throw(...) now produces a stack trace the same way engine errors do.
• Filename population. ChaiScript_Basic::eval() at chaiscript_engine.hpp:697-716 fills in ee.filename when it's empty, so test_script.chai actually appears in pretty_print().
• Cross-eval identity preserved. internal_eval / internal_eval_file unwrap the boxed_value() back out of the eval_error so nested eval() calls keep script-level exception identity — this is important for script-level try/catch semantics.
• Ergonomic API. has_boxed_value(), boxed_value(), and rethrow_typed<Types...>(engine) are the single-catch-point + auto-unboxing payoff from Derive eval_exception from std::nested_exception and wrap all thrown exceptions with eval_exception #63. Tests cover all of it (compiled_tests.cpp:266-347).

One caveat carried over from the earlier review: when a caller passes an Exception_Handler (exception_specification<...>()), a matching typed exception still escapes unwrapped — that's the backward-compat path. It's documented in tests ("exception_specification still auto-unboxes for backward compatibility") but worth mentioning in user docs too.

Does it address #515?

Yes, in the part that was actually broken. Issue #515 asks for line numbers on exceptions. Engine-produced eval_errors (parse errors, "can not find object", dispatch errors) have always carried start_position.line and filename — that side of #515 has been answered since before this PR. What #515 was really exposing is that script-thrown exceptions (throw(42)) surfaced as a raw Boxed_Value with zero positional information — no line, no file, no stack. This PR fixes exactly that: script throws are now wrapped in eval_error with a populated call_stack and filename, so pretty_print() / start_position / call_stack[0].start().line all work the same for script throws as for engine errors.

What this PR does not add is a dedicated programmatic accessor like the get_info(int& line, std::string& file, std::string& msg) helper the #515 commenter wrote for themselves. Users still read start_position.line, filename, and walk call_stack directly. If that convenience is desired, it'd be a small follow-up — but the underlying data #515 wanted is now reachable for the case where it previously wasn't.

Recommendation

1. Merge develop into the branch and resolve the compiled_tests.cpp conflict (likely around the exception tests that both sides touched in Fix #61: Thoroughly test throwing of exceptions from various contexts #681).
2. Re-run CI; investigate the ASAN+UBSAN Release failure if it reproduces.
3. Consider closing Line numbers for exceptions/errors #515 explicitly when this merges, with a note pointing at the call_stack / filename fields and pretty_print(). Optionally add a small get_info()-style accessor if you want to match the shape of what the reporter asked for.