Improving the error handling #80

BRO3886 · 2025-02-12T07:36:28Z

BRO3886
Feb 12, 2025

Improving the error handling

Flexprice follows a layered architecture:

API Layer (Gin Handlers)
Service Layer (Business Logic)
Repository Layer (Ent ORM)

Each layer currently implements its own error handling patterns, leading to inconsistency and maintenance challenges. There needs to be a unified approach that provides:

Clear error context for developers
Safe error messages for API consumers
Consistent error patterns across services
Easy integration with ent

Issues in the Current Solution

1. Inconsistent Error Wrapping

// In service layer
return nil, errors.Wrap(err, errors.ErrCodeValidation, "invalid address")

// In repository layer
return errors.Wrap(err, errors.ErrCodeInvalidOperation, "failed to create customer")

Multiple wrapping layers make it hard to track error origin
Inconsistent error codes across layers

2. Mixed Error Types

// Domain-specific errors
var ErrInvoiceNotFound = errors.New("invoice not found")

// Generic internal errors
errors.Wrap(err, errors.ErrCodeInvalidOperation, "failed to create")

Confusion between domain errors and system errors

3. HTTP Response Handling

if err != nil {
    c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
    return
}

Direct exposure of internal error messages
Manual mapping of errors to HTTP status codes
Inconsistent response formats

There needs to be a solution that's generic and scalable. It should offer transparency to clients with proper classification, along with context and proper logging for internal debugging (for developers)