Skip to content

fix: standardize error handling in follow route#205

Open
pari7maheshwari wants to merge 1 commit into
Dev-Card:mainfrom
pari7maheshwari:fix-follow-error-handling
Open

fix: standardize error handling in follow route#205
pari7maheshwari wants to merge 1 commit into
Dev-Card:mainfrom
pari7maheshwari:fix-follow-error-handling

Conversation

@pari7maheshwari
Copy link
Copy Markdown

Summary

Here’s your PR template filled based on our last discussion (error handling standardization / unsafe catch blocks fix):


PR Title

Standardize error handling in catch blocks and improve type safety


Description

This PR improves error handling consistency across the codebase by replacing unsafe error access patterns in catch blocks with properly typed and validated error handling. It ensures safer runtime behavior, better TypeScript compliance, and more predictable error logging.

Closes #


Type of Change

  • Refactor (no functional change)

What Changed

  • Updated multiple catch (error) blocks to safely handle unknown error types
  • Replaced unsafe direct error.message access with type-guarded handling (e.g. instanceof Error)
  • Standardized error logging format across affected files
  • Improved TypeScript safety in error handling paths

How to Test

  1. Run the application locally

  2. Trigger API failures / error scenarios (network failure, invalid request, etc.)

  3. Verify:

    • No runtime crashes from undefined error properties
    • Errors are logged properly and consistently
  4. Run type checks and ensure no TypeScript errors appear


Checklist

  • My code follows the project's coding style (pnpm -r run lint passes)
  • TypeScript compiles without errors (pnpm -r run typecheck passes)
  • I have added or updated tests for the changes I made (N/A or optional depending on setup)
  • All tests pass locally (pnpm -r run test)
  • I have updated documentation where necessary (not required for internal refactor)
  • No new console.log or debug statements left in the code
  • Breaking changes are documented in this PR description (none)

Screenshots / Recordings

Not applicable (internal refactor, no UI changes)


Additional Context

This change is part of improving overall reliability and consistency of error handling across the project. It helps prevent runtime issues caused by unsafe assumptions about thrown error types and prepares the codebase for stricter TypeScript configurations in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant