Enhance Error Handling with Custom Error Types

[coderabbitai]

As discussed in PR #316 and this comment by @AndlerRL, we need to improve error handling across the codebase by:

• Creating a set of error codes with their types (e.g., custom error classes like URLBuilderError).
• Analyzing which parts of the code need enhanced error handling.
• Providing steps to implement these improvements.

This issue will serve to track the progress of enhancing error handling practices throughout the project.

[AndlerRL]

@coderabbitai run an analysis to check error handling integrity and see for opportunities of adding this Error Handling System.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

Let me analyze the error handling patterns found in the codebase and provide recommendations for implementing a custom error handling system.

@AndlerRL Based on the analysis, here are the key findings and recommendations:

1. Current Error Handling Patterns:

• Most errors are thrown using generic Error class
• Common areas with error handling:
  • Environment validation (NEXT_PUBLIC_APP_ENV, AUTH_SECRET, etc.)
  • JWT operations (token validation, generation, refresh)
  • GraphQL type checking
  • Authentication/Authorization checks
  • AI model interactions

2. Proposed Custom Error Classes Structure:

// Base error class
export class MasterBotsError extends Error {
  constructor(message: string, public code: string) {
    super(message);
    this.name = this.constructor.name;
  }
}

// Authentication/Authorization errors
export class AuthError extends MasterBotsError {
  constructor(message: string) {
    super(message, 'AUTH_ERROR');
  }
}

// Environment configuration errors
export class ConfigError extends MasterBotsError {
  constructor(message: string) {
    super(message, 'CONFIG_ERROR');
  }
}

// JWT related errors
export class JWTError extends MasterBotsError {
  constructor(message: string) {
    super(message, 'JWT_ERROR');
  }
}

// AI/Model related errors
export class AIError extends MasterBotsError {
  constructor(message: string) {
    super(message, 'AI_ERROR');
  }
}

// GraphQL/API errors
export class APIError extends MasterBotsError {
  constructor(message: string) {
    super(message, 'API_ERROR');
  }
}

3. Implementation Areas:

Replace current error throws with custom errors. Examples:

// Before:
if (!session) {
  throw new Error('Unauthorized: No user session found');
}

// After:
if (!session) {
  throw new AuthError('No user session found');
}

// Before:
if (!process.env.NEXT_PUBLIC_APP_ENV) {
  throw new Error("NEXT_PUBLIC_APP_ENV is not set");
}

// After:
if (!process.env.NEXT_PUBLIC_APP_ENV) {
  throw new ConfigError("NEXT_PUBLIC_APP_ENV is not set");
}

// Before:
throw new Error("Invalid token");

// After:
throw new JWTError("Invalid token");

4. Error Handling Middleware:

export function errorHandler(error: Error) {
  if (error instanceof MasterBotsError) {
    // Handle known errors
    console.error(`[${error.code}] ${error.message}`);
    // Add appropriate error reporting/logging
    return {
      code: error.code,
      message: error.message
    };
  }
  
  // Handle unknown errors
  console.error('[UNKNOWN_ERROR]', error);
  return {
    code: 'UNKNOWN_ERROR',
    message: 'An unexpected error occurred'
  };
}

5. Next Steps:
6. Create a new file src/errors/index.ts with the custom error classes
7. Gradually replace generic errors with custom errors across the codebase
8. Implement error handling middleware in API routes and GraphQL resolvers
9. Add error codes documentation
10. Set up error monitoring and reporting

Would you like me to create a GitHub issue to track this implementation? I can include the detailed steps and code examples.

🔗 Analysis chain

I'll help analyze the error handling integrity across the codebase. Let me search for error handling patterns and potential areas for improvement.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for try-catch blocks to understand current error handling
echo "=== Try-Catch Blocks ==="
rg "try\s*{" -A 2

echo -e "\n=== Error Throwing Patterns ==="
# Look for throw statements
rg "throw\s+(new\s+)?Error" -A 1

echo -e "\n=== Custom Error Classes ==="
# Search for custom error class definitions
ast-grep --pattern 'class $_ extends Error'

echo -e "\n=== Direct Error Constructor Usage ==="
# Find places where Error is directly constructed
rg "new Error\(" -A 1

echo -e "\n=== Console Error Logging ==="
# Find error logging patterns
rg "console\.(error|warn)" -A 1

echo -e "\n=== Error Related Function Names ==="
# Find functions that might be handling errors
rg "function.*(error|fail|handle.*error)" -B 1 -A 1

Length of output: 66957

---

✏️ Learnings added

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:47:33.288Z
Learning: Error handling in the masterbots codebase should use custom error classes extending from MasterBotsError base class, with specific error types for Auth, Config, JWT, AI, and API errors.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@AndlerRL Based on the analysis of the codebase, I've identified several areas where error handling can be improved. Here's a detailed breakdown:

1. Current Error Handling Patterns:

   • Heavy use of console.error for logging (80+ occurrences)
   • Generic error throwing with basic messages
   • Inconsistent error handling in API routes
   • Mixed error handling patterns in promise chains
   • No standardized error types for different scenarios

2. Key Areas Needing Enhanced Error Handling:

a. API Routes (apps/masterbots.ai/app/api/):

// Current pattern
catch (error) {
  console.error('Error in chat API route:', error)
  return NextResponse.json(
    { error: 'An error occurred while processing your request' },
    { status: 500 }
  )
}

// Should be improved to:
catch (error) {
  if (error instanceof APIError) {
    return NextResponse.json(
      { 
        code: error.code,
        message: error.message,
        details: error.details 
      },
      { status: error.statusCode }
    )
  }
  // Log and return a sanitized error for unexpected errors
  logger.error('Unexpected error in chat API', { error })
  return NextResponse.json(
    { 
      code: 'INTERNAL_SERVER_ERROR',
      message: 'An unexpected error occurred'
    },
    { status: 500 }
  )
}

b. Authentication (apps/masterbots.ai/auth.ts):

// Current pattern
console.error('User authentication failed: Invalid password')
throw new Error('Invalid credentials')

// Should be improved to:
throw new AuthError(
  'AUTH.INVALID_CREDENTIALS',
  'Invalid email or password provided',
  401,
  { email }
)

c. Payment Processing (apps/masterbots.ai/app/api/payment/):

// Current pattern
console.error('Error creating subscription:', error)
return new Response(JSON.stringify({ error: stripeError?.message }))

// Should be improved to:
throw new PaymentError(
  'PAYMENT.SUBSCRIPTION_FAILED',
  'Failed to create subscription',
  400,
  { 
    stripeError: error.raw,
    customerId,
    planId 
  }
)

3. Recommended Error Class Structure:

// src/errors/types.ts
export type ErrorCode = 
  | 'AUTH.INVALID_CREDENTIALS'
  | 'AUTH.TOKEN_EXPIRED'
  | 'PAYMENT.SUBSCRIPTION_FAILED'
  | 'PAYMENT.INVALID_CARD'
  | 'API.REQUEST_FAILED'
  | 'API.VALIDATION_FAILED'
  | 'CHAT.MESSAGE_FAILED'
  | 'CHAT.THREAD_NOT_FOUND'
  // ... more error codes

// src/errors/base.error.ts
export class BaseError extends Error {
  constructor(
    public code: ErrorCode,
    message: string,
    public statusCode: number = 500,
    public details?: Record<string, unknown>
  ) {
    super(message)
    this.name = this.constructor.name
    Error.captureStackTrace(this, this.constructor)
  }

  toJSON() {
    return {
      code: this.code,
      message: this.message,
      statusCode: this.statusCode,
      details: this.details
    }
  }
}

// src/errors/auth.error.ts
export class AuthError extends BaseError {
  constructor(
    code: ErrorCode,
    message: string,
    statusCode = 401,
    details?: Record<string, unknown>
  ) {
    super(code, message, statusCode, details)
  }
}

// src/errors/payment.error.ts
export class PaymentError extends BaseError {
  constructor(
    code: ErrorCode,
    message: string,
    statusCode = 400,
    details?: Record<string, unknown>
  ) {
    super(code, message, statusCode, details)
  }
}

// src/errors/api.error.ts
export class APIError extends BaseError {
  constructor(
    code: ErrorCode,
    message: string,
    statusCode = 500,
    details?: Record<string, unknown>
  ) {
    super(code, message, statusCode, details)
  }
}

4. Implementation Steps:

5. Create error classes and types in a new src/errors directory

6. Replace generic error throws with specific error types

7. Implement error logging middleware

8. Add error handling utilities for common scenarios

9. Update API responses to use standardized error formats

10. Add error documentation

Would you like me to create a GitHub issue to track the implementation of this error handling system with these specific recommendations?

🔗 Analysis chain

I'll help analyze the error handling patterns in the codebase to identify opportunities for implementing a custom error handling system. Let me gather the necessary information.

Let me analyze the results and provide a comprehensive review of error handling patterns and opportunities for improvement.

Based on the gathered information, I'll provide a detailed analysis and recommendations for implementing a custom error handling system.

@AndlerRL After analyzing the codebase, here's a comprehensive review of the current error handling patterns and recommendations for implementing a robust error handling system:

1. Current Error Handling Patterns:

   • Most errors are handled using generic Error class
   • Inconsistent error message formatting
   • Mix of console.error and thrown errors
   • Some promise chains lack proper error handling

2. Recommended Error Handling System:

// src/errors/base.error.ts
export class BaseError extends Error {
  constructor(
    public code: string,
    message: string,
    public statusCode: number = 500,
    public details?: unknown
  ) {
    super(message);
    this.name = this.constructor.name;
    Error.captureStackTrace(this, this.constructor);
  }
}

// src/errors/api.error.ts
export class APIError extends BaseError {
  constructor(
    code: string,
    message: string,
    statusCode: number = 500,
    details?: unknown
  ) {
    super(code, message, statusCode, details);
  }
}

// src/errors/validation.error.ts
export class ValidationError extends BaseError {
  constructor(message: string, details?: unknown) {
    super('VALIDATION_ERROR', message, 400, details);
  }
}

// src/errors/network.error.ts
export class NetworkError extends BaseError {
  constructor(message: string, details?: unknown) {
    super('NETWORK_ERROR', message, 503, details);
  }
}

// src/errors/index.ts
export const ErrorCodes = {
  VALIDATION: {
    INVALID_INPUT: 'VALIDATION.INVALID_INPUT',
    MISSING_REQUIRED: 'VALIDATION.MISSING_REQUIRED',
  },
  API: {
    REQUEST_FAILED: 'API.REQUEST_FAILED',
    RESPONSE_PARSING: 'API.RESPONSE_PARSING',
  },
  NETWORK: {
    CONNECTION_FAILED: 'NETWORK.CONNECTION_FAILED',
    TIMEOUT: 'NETWORK.TIMEOUT',
  },
} as const;

export * from './base.error';
export * from './api.error';
export * from './validation.error';
export * from './network.error';

3. Implementation Areas:

Here are the key areas where we should implement the new error handling system:

a. API Calls:

try {
  const response = await fetch(url);
  if (!response.ok) {
    throw new APIError(
      ErrorCodes.API.REQUEST_FAILED,
      `API request failed: ${response.statusText}`,
      response.status,
      { url, method: 'GET' }
    );
  }
} catch (error) {
  if (error instanceof APIError) {
    // Handle API specific errors
    logger.error(error);
  } else {
    // Handle unexpected errors
    throw new NetworkError(
      `Unexpected error during API call: ${error.message}`,
      { originalError: error }
    );
  }
}

b. Input Validation:

function validateInput(data: unknown): void {
  if (!data) {
    throw new ValidationError(
      'Data is required',
      { code: ErrorCodes.VALIDATION.MISSING_REQUIRED }
    );
  }
  // More validation...
}

4. Implementation Steps:

5. Create a new errors directory with the error classes shown above

6. Implement error codes enum for consistent error identification

7. Update existing error throws to use the new custom error classes

8. Add error handling middleware/utilities for consistent error processing

9. Update logging to include error codes and details

10. Add error documentation for different error types and their meanings

11. Best Practices to Follow:

• Always extend from BaseError for custom error types
• Include meaningful error codes from ErrorCodes enum
• Add relevant details to help with debugging
• Use appropriate HTTP status codes for API errors
• Implement proper error logging with error details
• Handle errors at appropriate levels (don't catch errors too early)

Would you like me to create a GitHub issue to track the implementation of this error handling system? I can include these recommendations and implementation steps in the issue for better tracking.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for try-catch blocks to analyze current error handling patterns
echo "=== Try-Catch Patterns ==="
rg "try\s*{" -A 5

echo -e "\n=== Error Throwing Patterns ==="
# Look for throw statements
rg "throw\s+(new\s+)?Error" -A 2

echo -e "\n=== Custom Error Classes ==="
# Look for potential custom error class definitions
ast-grep --pattern 'class $_ extends Error'

echo -e "\n=== Error Related Function Names ==="
# Look for functions that might be handling errors
rg "function.*(error|handle|fail|exception)" -i

Length of output: 67081

---

Script:

#!/bin/bash
# Look for error messages being used
echo "=== Error Messages ==="
rg '".*error.*"' --type ts --type js -A 1

echo -e "\n=== Console Error Usage ==="
# Check console.error usage
rg "console\.error" -A 2

echo -e "\n=== Promise Error Handling ==="
# Look for promise error handling
rg "\.catch\(" -A 2

Length of output: 29910

---

✏️ Learnings added

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:48:38.995Z
Learning: Error handling in the project should use a hierarchical error class system with BaseError as the parent class and specific error types (AuthError, PaymentError, APIError) for different domains. Each error should include a standardized error code, message, status code, and optional details.

---

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:48:38.995Z
Learning: API routes in the project should handle errors by catching specific error types, logging appropriately, and returning standardized error responses with proper HTTP status codes. Unexpected errors should be logged but return sanitized error messages to clients.

---

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:48:38.995Z
Learning: Error codes in the project should follow a domain-based naming convention (e.g., 'AUTH.INVALID_CREDENTIALS', 'PAYMENT.SUBSCRIPTION_FAILED') and be defined as TypeScript string literals for type safety.

---

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:48:38.995Z
Learning: The project requires a custom error handling system with specific error classes (BaseError, APIError, ValidationError, NetworkError) that extend the Error class. Each error should include a code, message, status code, and optional details.

---

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:48:38.995Z
Learning: Error codes in the project should follow a hierarchical structure (e.g., 'VALIDATION.INVALID_INPUT', 'API.REQUEST_FAILED') and be defined in a central ErrorCodes constant.

---

Learnt from: AndlerRL
URL: https://github.com/bitcashorg/masterbots/issues/329

Timestamp: 2024-12-10T06:48:38.995Z
Learning: API error handling should use custom APIError class with appropriate status codes and include request details for debugging purposes.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.