Error Handling in Tool-Methoden vereinheitlichen #32

New issue

Closed

opened 2026-03-08 09:26:08 +00:00 by automation · 1 comment

automation commented

2026-03-08 09:26:08 +00:00

Collaborator

Problem

Jede Tool-Methode in RefactoringTools hat eigenes try/catch mit leicht unterschiedlichem Error-Format:

Manche geben exceptionType und stackTrace zurück
Manche nur message
Manche nutzen MAPPER.writeValueAsString, andere plain Strings

Auswirkung

Inkonsistente Error-Responses für den MCP-Client. Schwer zu debuggen.

Vorgeschlagener Fix

Gemeinsame Error-Handler-Methode:

private static CallToolResult errorResult(String tool, Exception e) {
    Map<String, Object> error = new HashMap<>();
    error.put("status", "ERROR");
    error.put("message", "Error during " + tool + ": " + e.getMessage());
    error.put("exceptionType", e.getClass().getSimpleName());
    // ... einheitlich
}

Kontext

Identifiziert bei der Architektur-Analyse durch Agent jdt-gamma (Erich Gamma).

## Problem Jede Tool-Methode in `RefactoringTools` hat eigenes try/catch mit leicht unterschiedlichem Error-Format: - Manche geben `exceptionType` und `stackTrace` zurück - Manche nur `message` - Manche nutzen `MAPPER.writeValueAsString`, andere plain Strings ## Auswirkung Inkonsistente Error-Responses für den MCP-Client. Schwer zu debuggen. ## Vorgeschlagener Fix Gemeinsame Error-Handler-Methode: ```java private static CallToolResult errorResult(String tool, Exception e) { Map<String, Object> error = new HashMap<>(); error.put("status", "ERROR"); error.put("message", "Error during " + tool + ": " + e.getMessage()); error.put("exceptionType", e.getClass().getSimpleName()); // ... einheitlich } ``` ## Kontext Identifiziert bei der Architektur-Analyse durch Agent jdt-gamma (Erich Gamma).

automation added the

P3-medium

refactoring

labels

2026-03-08 09:26:08 +00:00

automation commented

2026-03-08 18:12:04 +00:00

Author

Collaborator

Umgesetzt in `49bee74`

Neue Utility-Klasse ToolErrors mit zentraler errorResult(toolName, Exception) Methode.

Einheitliches JSON-Format

{
  "status": "ERROR",
  "message": "Error during <toolName>: <exception message>",
  "exceptionType": "IllegalArgumentException",
  "cause": "root cause message"
}

Geänderte Dateien

Neu: ToolErrors.java — zentrale Error-Response-Methode + automatisches Logging via McpLogger
14 Tool-Klassen umgestellt (~40 catch-Blöcke): RefactoringTools, RenameRefactoring, CreationTools, CodeGenerationTools, NavigationTools, CodeAnalysisTools, DocumentationTools, CodeQualityTools, ProjectInfoTools, ExecutionTools, ImportOrganizer, ExtractInterfaceRefactoring, ConvertToLambdaRefactoring
Netto -129 Zeilen (von ~200 Zeilen Error-Code auf je 1 Zeile pro catch)

Verbesserungen

Alle Exceptions werden jetzt geloggt (vorher fehlte Logging bei ~60% der Catches)
cause wird automatisch mitgegeben wenn vorhanden
Kein Plain-String vs. JSON-Mix mehr

## Umgesetzt in `49bee74` Neue Utility-Klasse `ToolErrors` mit zentraler `errorResult(toolName, Exception)` Methode. ### Einheitliches JSON-Format ```json { "status": "ERROR", "message": "Error during <toolName>: <exception message>", "exceptionType": "IllegalArgumentException", "cause": "root cause message" } ``` ### Geänderte Dateien - **Neu:** `ToolErrors.java` — zentrale Error-Response-Methode + automatisches Logging via `McpLogger` - **14 Tool-Klassen umgestellt** (~40 catch-Blöcke): RefactoringTools, RenameRefactoring, CreationTools, CodeGenerationTools, NavigationTools, CodeAnalysisTools, DocumentationTools, CodeQualityTools, ProjectInfoTools, ExecutionTools, ImportOrganizer, ExtractInterfaceRefactoring, ConvertToLambdaRefactoring - **Netto -129 Zeilen** (von ~200 Zeilen Error-Code auf je 1 Zeile pro catch) ### Verbesserungen - Alle Exceptions werden jetzt **geloggt** (vorher fehlte Logging bei ~60% der Catches) - `cause` wird automatisch mitgegeben wenn vorhanden - Kein Plain-String vs. JSON-Mix mehr

automation closed this issue

2026-03-08 18:12:09 +00:00