Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Error Handling #24

Open
elersong opened this issue Jul 13, 2024 · 0 comments
Open

Refactor Error Handling #24

elersong opened this issue Jul 13, 2024 · 0 comments
Labels
enhancement New feature or request from_willyovale An issue described in original project, but never implemented good first issue Good for newcomers

Comments

@elersong
Copy link
Owner

Description

Fireorm can throw different types of errors, including Firestore errors, validation errors, and other generic errors. Currently, error declarations are scattered throughout the codebase, leading to duplicated and inconsistent error handling. To improve maintainability and readability, error handling should be centralized.

Steps to Reproduce

  1. Trigger different types of errors in Fireorm.
  2. Observe the scattered and duplicated error declarations.

Expected Behavior

Centralized error handling with consistent error messages and types, reducing code duplication and improving maintainability.

Actual Behavior

Error declarations are scattered throughout the codebase, leading to duplicated and inconsistent error handling.

Acceptance Criteria

  • Refactor new Error() instances in the codebase by creating centralized error definitions in src/Errors.
  • Remove duplicated error declarations.
  • Ensure consistent error handling throughout the codebase.

Additional Context

  • October 17, 2020: Initial proposal to refactor error handling in Fireorm.

Proposed API Changes

  1. Centralize Error Definitions:

    • Create a centralized location for error definitions in src/Errors.
    // src/Errors/index.ts
    export class FirestoreError extends Error {
      constructor(message: string) {
        super(message);
        this.name = 'FirestoreError';
      }
    }
    
    export class ValidationError extends Error {
      constructor(message: string) {
        super(message);
        this.name = 'ValidationError';
      }
    }
    
    export class GenericError extends Error {
      constructor(message: string) {
        super(message);
        this.name = 'GenericError';
      }
    }
  2. Refactor Error Handling in Codebase:

    • Replace all instances of new Error() with the appropriate custom error classes.
    import { FirestoreError, ValidationError, GenericError } from './Errors';
    
    // Example refactoring
    try {
      // some Firestore operation
    } catch (error) {
      throw new FirestoreError('Failed to perform Firestore operation');
    }
    
    if (this.config.validateModels) {
      const errors = await validate(item);
      if (errors.length) {
        throw new ValidationError('Model validation failed');
      }
    }
    
    if (someOtherCondition) {
      throw new GenericError('An unknown error occurred');
    }
  3. Remove Duplicated Error Declarations:

    • Identify and remove any duplicated error declarations throughout the codebase.

Example Implementation

@Collection()
class User {
  @IsString()
  id: string;

  @IsString()
  display_name: string;

  @IsString()
  username: string;
}

// Repository instance
class UserRepository {
  async create(user: User) {
    try {
      // create logic
    } catch (error) {
      throw new FirestoreError('Failed to create user');
    }
  }

  async update(user: User) {
    try {
      // update logic
    } catch (error) {
      throw new FirestoreError('Failed to update user');
    }
  }
}

Original Issue

@elersong elersong added enhancement New feature or request good first issue Good for newcomers from_willyovale An issue described in original project, but never implemented labels Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request from_willyovale An issue described in original project, but never implemented good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant