Error Handling

Field Details
Status Active
Last Updated 04-22-2026

Purpose

To ensure consistent and secure error handling across all applications

Scope

Applies to: All backend services, frontend applications, APIs

Does not apply to: Third-party libraries

Rules

  • Never swallow exceptions silently
  • Always log the error before throwing or returning
  • Use custom exception classes — never throw raw Exception
  • Always include a meaningful message
  • Do not expose internal error details like stack trace to the API

Custom Exceptions

// Good examples:
throw new PaymentFailedException("Payment declined for order #123")
throw new HappiExceptionHandle("Payment declined for order #123")

// Avoid:
throw new Exception("error")
catch (Exception e) { } // empty catch

API Error Response Format

All APIs must return errors in this structure:

{
  "status": 400,
  "code": "INVALID_REQUEST",
  "message": "Invoice ID is required",
  "timestamp": "2024-01-01T10:00:00Z"
}

  • Use this for error reference Error Responses

  • code → machine-readable, UPPER_SNAKE_CASE

  • message → human-readable, safe to show to users
  • Never include stack traces in API responses

Common Mistakes to Avoid

return null;               // use Optional or throw instead
catch (Exception e) { }    // never have empty catch blocks
e.printStackTrace();       // use a proper logger instead

Exceptions

No exceptions.

Changelog

Version Date Author Change
1.0.0 04-22-2026 Tibin Sunny Initial version