Skip to main content

API Error Handling

How LibreApps Desktop communicates and manages errors in its APIs.

Overview​

A well-designed error handling system is crucial for debugging and providing a good user experience. LibreApps Desktop uses a standardized error response format across all its microservices.

Error Response Format​

When an error occurs, the API returns a JSON object with the following structure:

{
  "timestamp": "2024-05-20T10:00:00Z",
  "status": 400,
  "error": "Bad Request",
  "message": "The 'email' field is required.",
  "path": "/api/users/register",
  "code": "VALIDATION_ERROR"
}

Fields​

  • timestamp: The time the error occurred.
  • status: The HTTP status code.
  • error: A short description of the HTTP status.
  • message: A human-readable message explaining the error.
  • path: The URL path where the error occurred.
  • code: A machine-readable error code for specific error types.

Handling Errors in the Frontend​

The LibreApps Desktop frontend uses an Axios interceptor to catch API errors and display them to the user using toast notifications or inline error messages.

api.interceptors.response.use(
  (response) => response,
  (error) => {
    const message = error.response?.data?.message || 'An unexpected error occurred.';
    toast.error(message);
    return Promise.reject(error);
  }
);

Best Practices​

  • ✅ Do this: Use specific HTTP status codes to indicate the type of error.
  • ✅ Do this: Provide clear and actionable error messages that help the user or developer resolve the issue.
  • ❌ Don't do this: Return stack traces or sensitive internal information in the error response.