Feature: Exception Call Chain System for API Contextualization
Description
Following the successful migration of exceptions (100% completed), this project aims to implement a Call Chain System to contextualize exceptions at the API level.
Problem
Currently, exceptions provide detailed internal context (e.g., _validate_state_dimension) but fail to show the high-level user action, especially during nested API calls.
- Example: A user calls
build_initial_guess, which calls initial_guess, which fails in initial_state. The current error only shows the initial_state context, hiding that the error originated from build_initial_guess and confusing the user about the source of the error.
Proposed Solution
Implement a thread-local tracking system to capture the hierarchy of public API calls and wrap exceptions with this full context.
Key Technical Components
- Thread-Local Stack: A mechanism (
push_api_call!, pop_api_call!) to track active API calls.
- New Exception Types:
APICallInfo: Struct to store function name, signature, and user action description.
APICallChain: New exception type wrapping the original CTModelsException and the captured call_stack.
@api_function Macro: A macro to automate stack management and exception wrapping for public API functions.
Scope
Approximately 20-25 functions will be wrapped across 4 priority tiers:
- Tier 1 (Core):
state!, control!, time!, dynamics!, objective!, build.
- Tier 2 (OCP Extended):
variable!, constraint!, definition!, time_dependence!.
- Tier 3 (Initial Guess):
initial_guess, build_initial_guess, validate_initial_guess.
- Tier 4 (Serialization):
export_ocp_solution, import_ocp_solution.
Expected Outcome
Error messages will transparently display an "API Call Chain" section, detailing the path from the user's entry point down to the internal validation failure.
Feature: Exception Call Chain System for API Contextualization
Description
Following the successful migration of exceptions (100% completed), this project aims to implement a Call Chain System to contextualize exceptions at the API level.
Problem
Currently, exceptions provide detailed internal context (e.g.,
_validate_state_dimension) but fail to show the high-level user action, especially during nested API calls.build_initial_guess, which callsinitial_guess, which fails ininitial_state. The current error only shows theinitial_statecontext, hiding that the error originated frombuild_initial_guessand confusing the user about the source of the error.Proposed Solution
Implement a thread-local tracking system to capture the hierarchy of public API calls and wrap exceptions with this full context.
Key Technical Components
push_api_call!,pop_api_call!) to track active API calls.APICallInfo: Struct to store function name, signature, and user action description.APICallChain: New exception type wrapping the originalCTModelsExceptionand the capturedcall_stack.@api_functionMacro: A macro to automate stack management and exception wrapping for public API functions.Scope
Approximately 20-25 functions will be wrapped across 4 priority tiers:
state!,control!,time!,dynamics!,objective!,build.variable!,constraint!,definition!,time_dependence!.initial_guess,build_initial_guess,validate_initial_guess.export_ocp_solution,import_ocp_solution.Expected Outcome
Error messages will transparently display an "API Call Chain" section, detailing the path from the user's entry point down to the internal validation failure.