A. Pain Points of Project Error Handling
In business projects, we often encounter the following pain points.
1. Lack of a Unified Error Handling Solution, Logs All Over the Code
To facilitate problem location when an interface fails, logs are seen everywhere in the code, taken as a matter of course. However, this overwhelming amount of disorganized logs usually increases maintenance workload without achieving its intended purpose.
2. Lack of an Error Stack After a Request Error, Making It Difficult to Quickly Locate Issues
For example, when an ‘error’-level mistake occurs at the lower level, only one error message is visible at the top level. How can we troubleshoot this?
A screenshot from a real-world case investigation
3. Error Returns from Third-party Components Lack Stack Information
Not only third-party components, but all methods in the standard library return errors without a stack, posing a significant challenge for unified error handling at the business layer. Almost all errors returned from business layer code calls need to be wrapped again using methods like ‘Wrap’, so the business layer itself can achieve error stack returns. This maintenance cost is relatively high and almost relies on ‘CodeReview’ for human assurance, risking missing ‘Wrap’ handling.
4. Diverse Error Components, Projects Tend to Wrap Another Layer
There are many third-party error handling components. How to choose? Business projects often also wish to wrap another layer, further increasing the maintenance cost of error handling components.
B. Full Error Stack Design of the Framework
1. Unified Error Component
The ‘GoFrame’ framework provides the industry’s most powerful error handling component, which is also the error component widely used within the framework, reducing the choice cost for business teams.
2. Unified Error Handling Solution
The ‘GoFrame’ framework provides powerful engineering design specifications, including a necessary unified error handling solution. Through the unified framework’s engineering design, some common pain points have been solved through components and tools, allowing business teams to focus on the business itself, thereby making development work more efficient.
Under the unified error handling solution, all method calls in the project take the ‘error’ return value as the basis for execution success or failure. If ‘error’ is not ‘nil’, return quickly and pass it layer by layer upward to handle errors at the top level. Furthermore, the critical components of the framework have already provided default error handling logic.
3. Full Component Support for Stack Errors
🔥 The ‘GoFrame’ framework’s error return objects in all basic components include error stacks! 🔥
🔥 The ‘GoFrame’ framework’s error return objects in all basic components include error stacks! 🔥
🔥 The ‘GoFrame’ framework’s error return objects in all basic components include error stacks! 🔥
🔥 Repeating important things three times! 🔥
This is a challenging feat because the components provided by the framework can cover almost all the needs of business projects, yet the framework indeed achieved it. Although the framework incurred significant initial costs (a separate version to realize this feature), it’s a one-time setup with long-term benefits. This means if business projects use the unified ‘GoFrame’ basic framework, error handling will be more straightforward, the risk of missing error stacks will be significantly reduced, and projects will be more robust and easier for quick troubleshooting.
4. Key Components Support Error Stack Printing
The framework’s key components provide default handling for error stack printing to improve usability and simplify the burden on users. These key components are the program’s entry points, like ‘HTTP/GRPC Server’ and ‘Command’ command lines.