Skip to main content
Use Droid Exec to refactor error messages across hundreds of files. The workflow finds ResponseError instantiations and improves messages so they are more descriptive, actionable, and user-friendly.
ResponseError is Factory’s internal error handling class used to throw HTTP-style errors with specific status codes. These error classes are used throughout the codebase to handle API errors.

How it works

The script:
  1. Finds files: Searches for all .ts and .tsx files containing ResponseError classes
  2. Filters smartly: Excludes node_modules, .git, dist, build, and .next directories
  3. Identifies errors: Locates all ResponseError instantiations (400, 401, 403, 404, etc.)
  4. Improves messages: Makes them more descriptive and actionable
  5. Adds context: Includes what went wrong and potential fixes
  6. User-friendly language: Removes technical jargon
  7. Preserves metadata: Keeps error codes and metadata intact

Get the script

Prerequisites

Before you begin, complete the Droid Exec installation.

Basic usage

Preview changes (dry run)

Always start with a dry run to see how many error messages need improvement before modifying files.
The dry run feature shows you exactly which files contain ResponseError instantiations and how many:
How dry run works:
  • When DRY_RUN=true: Counts all ResponseError instantiations without making changes
  • When DRY_RUN=false (default): Actually improves the error messages using AI
This helps you:
  • Estimate the scope of changes needed
  • Test on a small directory first
  • Plan your refactoring strategy

Apply refactoring

Once you’re ready, run the actual error message improvement:
Actual execution example:

Real-world transformations

Example 1: Session Authentication

Example 2: Bearer Token Authorization

Best practices

Follow these best practices for safe and effective error message improvement.
1

Start with a dry run

Always preview the scope of changes first:
2

Process incrementally

For large codebases, tackle one module at a time: