Client-Side Script Error Processing via Double Code Injection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Debugging complex client-side scripts, such as those used in AJAX applications, is challenging due to the different contexts of the user's application and its associated script engines, making it difficult to collect and handle run-time error information effectively.
Innovation Solution
A double code-injection technique is employed, where native program code is injected into a client-side application to instrument the scripting engine, allowing for the collection and return of detailed run-time error information, specifically a stack trace, only when a script error occurs, thereby minimizing processing overhead for error-free scripts.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If native program code is injected into a client-side application to collect detailed run-time error information, then measurement precision of error information is improved, but device complexity increases
Solution Approach 1:
The patent uses an intermediary error handling function that is injected into the scripting engine. This intermediary function acts as a mediator between the native program code and the scripting engine, collecting detailed run-time error information including stack traces without requiring direct complex interactions between the native code and engine internals.
Solution Approach 2:
The error collection process is segmented into distinct phases: (1) injecting the error handling function into the scripting engine, (2) the scripting engine executing scripts and calling the error function when errors occur, (3) collecting error information in a structured format, and (4) returning the collected information to the native program. This segmentation simplifies the overall complexity by breaking down the monolithic error handling into manageable components.
2Reliability
If error handling code is injected into the scripting engine, then reliability of error information collection is improved, but productivity of script execution decreases
Solution Approach 1:
The error handling function is activated periodically only when script errors occur, rather than continuously during normal script execution. The injected function monitors for error conditions and executes its collection logic selectively, ensuring reliable error information capture while minimizing interference with normal script execution performance.
Solution Approach 2:
The error handling mechanism is self-activating through the scripting engine's native error reporting infrastructure. When a script error occurs, the scripting engine automatically calls the injected error handling function with relevant error parameters, eliminating the need for continuous polling or manual intervention and maintaining high script execution productivity.
3Measurement precision
If detailed run-time information is collected for every script error, then measurement precision of error diagnostics is improved, but loss of time increases
Solution Approach 1:
The error handling function is pre-configured with the appropriate data structures and collection logic before script execution begins. When an error occurs, the function immediately captures detailed run-time information including stack traces using pre-allocated memory structures, avoiding the time overhead of dynamic allocation or complex processing during the error event itself.
Solution Approach 2:
The error information is collected in a standardized parameter format that facilitates efficient processing and storage. By changing the representation of error data into a consistent structured format with predefined parameters, the system achieves high measurement precision while reducing the time required for error analysis and debugging operations.
Data Source
AI summary
Systems, methods, and computer readable media for collecting run-time error information for an executing script through the use of a double code-injection technique are described. A first native code injection into a user's client-side application (e.g., a browser application) is made. The second injection is thereafter made by the user's client-side application itself (when the first injected program code is executed) into the application's associated scripting engine and only when a script error has been detected. The second injected program code or scripts collect detailed run-time script error information within the context of the application's scripting engine. The second injected program code can then return the collected error information to the user application's context where it may be provided to a debug tool or recorded for later review (by the first injected program code).


