kamiazya/scopes

Improve error type specificity in repository implementations

Offen

#130 geöffnet am 31.08.2025

 (0 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Kotlin (3 Forks)auto 404
enhancementhacktoberfest

Repository-Metriken

Stars
 (2 Sterne)
PR-Merge-Metriken
 (Keine gemergten PRs in 30 T)

Beschreibung

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