playbooks

home / skills / oimiragieo / agent-studio / globalexceptionhandler-class

globalexceptionhandler-class skill

/.claude/skills/_archive/dead/globalexceptionhandler-class

This skill helps enforce global exception handler patterns in JavaScript projects, improving reliability and consistency across error handling implementations.

npx playbooks add skill oimiragieo/agent-studio --skill globalexceptionhandler-class

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
1.4 KB
---
name: globalexceptionhandler-class
description: Structure of GlobalExceptionHandler class.
version: 1.0.0
model: sonnet
invoked_by: both
user_invocable: true
tools: [Read, Write, Edit]
globs: '**/src/main/java/com/example/GlobalExceptionHandler.java'
best_practices:
  - Follow the guidelines consistently
  - Apply rules during code review
  - Use as reference when writing new code
error_handling: graceful
streaming: supported
---

# Globalexceptionhandler Class Skill

<identity>
You are a coding standards expert specializing in globalexceptionhandler class.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

</instructions>

<examples>
Example usage:
```
User: "Review this code for globalexceptionhandler class compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

Overview

This skill helps developers design and review a GlobalExceptionHandler class for JavaScript applications. It focuses on structure, error classification, consistent response shapes, and safe logging. The guidance targets maintainability, security, and predictable client behavior.

How this skill works

The skill inspects a handler's responsibilities: exception capture, error mapping to HTTP statuses, logging severity, and response payloads. It checks for separation of concerns, idempotent behavior, and protection of sensitive data in error messages. The output includes concrete refactor suggestions and patterns to adopt.

When to use it

  • When creating a central error handler for an Express, Fastify, or similar server.
  • When standardizing API error responses across services.
  • When introducing structured logging and correlation IDs for errors.
  • When converting ad hoc try/catch blocks into a unified strategy.
  • When auditing error-handling for security or compliance requirements.

Best practices

  • Keep the handler thin: map errors to status codes and standardized payloads, delegate business logic elsewhere.
  • Differentiate operational errors (client input) from programmer errors (bugs) and respond accordingly.
  • Avoid leaking internal details: return generic messages and include a reference ID for support lookup.
  • Log full error context at the server level, including stack traces and correlation IDs, but never log secrets.
  • Use typed or tagged error classes to simplify mapping and unit testing of error flows.

Example use cases

  • Implementing a single Express middleware that formats all API errors as {status, code, message, id}.
  • Refactoring multiple route-level try/catch blocks into a centralized handler to reduce duplication.
  • Adding integration with an observability backend (Sentry, Datadog) while keeping client responses minimal.
  • Creating a test suite that verifies status mapping for validation, auth, and unexpected errors.

FAQ

Should the handler modify error objects before logging?

Sanitize sensitive fields and augment with context like request id, route, and user id; avoid altering the original stack trace.

How to handle third-party library errors?

Wrap or translate external errors into your domain error types so mapping remains consistent and testable.