kamiazya/scopes

Improve error type specificity in repository implementations

Open

#130 opened on Aug 31, 2025

 (0 comments) (0 reactions) (0 assignees)Kotlin (3 forks)auto 404
enhancementhacktoberfest

Repository metrics

Stars
 (2 stars)
PR merge metrics
 (PR metrics pending)

Description

Background

Gemini Code Assist review in PR #119 identified that repository implementations may return misleading error types for database failures. For example, returning InvalidDeviceError or NetworkError instead of more appropriate storage-specific errors.

Current Issue

When database operations fail, the error types don't accurately represent the actual failure:

  • Database connection errors might return NetworkError
  • Schema issues might return InvalidDeviceError
  • Storage failures lack specific error types

Proposed Solution

  1. Create specific error types for storage failures:

    • StorageError.ConnectionFailed
    • StorageError.SchemaError
    • StorageError.TransactionFailed
    • StorageError.ConstraintViolation
  2. Update repository implementations to return accurate error types

  3. Update tests to assert on specific error types

Example

// Current (misleading)
catch (e: SQLException) {
    Either.Left(SynchronizationError.InvalidDeviceError(...))
}

// Proposed (accurate)
catch (e: SQLException) {
    Either.Left(StorageError.DatabaseError(
        message = "Failed to access database",
        cause = e
    ))
}

Benefits

  • Better debugging with accurate error information
  • Clearer error handling in application layer
  • More maintainable error recovery strategies

Related

  • PR #119 - Where this was identified
  • Follows Error Handling Guidelines in docs/guidelines/error-handling.md

Priority

Medium - Improves error clarity but doesn't affect functionality

Contributor guide