Error Message Design for Distributed APIs
- Updated2023-02-17
- 1 minute(s) read
Error Message Design for Distributed APIs
Refer to the following table for best practices for designing error messages.
| Guideline | Required or Recommended? | Details |
|---|---|---|
|
Reserve a range of error codes for your API and use those codes for error conditions specific to your API. |
Required |
Pick a range for error codes between -8999 through -8000, 5000 through 9999, and 500,000 through 599,999, which are reserved for external users. |
|
When generating or manipulating errors on the diagram of your API VIs, make sure you use the Error API to construct and manipulate error clusters. |
Required |
Never bundle or unbundle error cluster elements directly in G Web Development Software. |
|
If the VI has no way to generate errors, consider excluding error inputs and outputs. |
Recommended |
If a VI does not generate errors, users of the VI can take advantage of parallelism in G Web Development Software. |
|
If you exclude error inputs and outputs on a VI in your API, leave the error input and output locations on the connector pane empty. |
Recommended |
When unused error inputs and outputs on a VI are left empty, you can add error handling to the VI later. |
Related Information
- Best Practices for Designing and Developing an Application Programming Interface (API) in G Web Development Software
To develop an API to distribute to other users that is consistent with NI style recommendations for G content, refer to the following best practice guidelines:
- File Organization and Node Naming for Distributed APIs
Refer to the following table for best practices for organizing files and naming nodes.
- Component Organization for Distributed APIs
Refer to the following table for best practices for organizing components.
- Icons and Connector Panes for Distributed APIs
Refer to the following table for best practices for creating icons and connector panes.
- Panel Design for Distributed APIs
Refer to the following table for best practices for designing panels.
- Data Type Selection for Distributed APIs
Refer to the following table for best practices for selecting data types.
- Palette Taxonomy for Distributed APIs
Refer to the following table for best practices for palette taxonomy.
- Documentation for Distributed APIs
Refer to the following table for best practices for documenting an API.
- API Design for Distributed APIs
Refer to the following table for best practices for designing VIs.