| `ValidationException` | `Presentation` | **422** | `Unprocessable Entity` | Échec de validation HTTP (`FormRequest`), champs invalides ou manquants. |
| `DomainException` | `Domain` | **422** | `Unprocessable Entity` | Violation d'un invariant ou d'une règle métier au cœur du Domaine (ex: `ValueObject`). |
| `NotFoundException` | `Application` | **404** | `Resource Not Found` | Ressource introuvable considérée comme exceptionnelle. |
| `NotFoundOutput` (polymorphisme) | `Application` / `Presentation` | **404** | `Resource Not Found` | Ressource absente attendue sur un use case de lecture (pas d'exception levée). |
| `HttpExceptionInterface` (403) | `Presentation` | **403** | `Forbidden` | Accès refusé par les politiques d'autorisation HTTP. |
| `ThrottleRequestsException` | `Infra` | **429** | `Too Many Requests` | Dépassement du quota de requêtes API (Rate Limiting). |
| `Throwable` / `Exception` | Transverse | **500** | `Internal Server Error` | Erreur système non captée (détails masqués hors mode debug). |
---
## 3. Format de Réponse (Problem Details)
Chaque réponse d'erreur retourne une structure JSON standardisée :
```json
{
"type": "http://localhost/errors/422",
"title": "Unprocessable Entity",
"status": 422,
"detail": "Invalid employee number format",
"instance": "/api/v1/employees",
"invalidParams": [
{
"name": "domain_invariant",
"reason": "Invalid employee number format"
}
]
}
```
---
## 4. Distinctions 400 Bad Request vs 422 Unprocessable Content
- **HTTP 400 (Bad Request)** : Réservé aux erreurs de **syntaxe ou de structure HTTP** (ex: JSON illisible, guillemets mal fermés, en-têtes HMAC malformés). Le serveur ne peut pas parser le message.
- **HTTP 422 (Unprocessable Content)** : Convention **REST & Laravel**. La requête est du JSON syntaxiquement valide, mais son contenu viole les règles de validation HTTP (`FormRequest`) ou les invariants du domaine métier (`DomainException`).
## 5. Ressources absentes dans les use cases de lecture
Pour les use cases de consultation (`Find*` / `Show*`), Arcadia API privilégie désormais un retour polymorphique :
-`Output` quand la ressource existe
-`NotFoundOutput` quand la ressource n'existe pas
Ce cas n'est pas traité comme une erreur exceptionnelle dans le cœur applicatif ; la couche `Presentation` convertit `NotFoundOutput` en réponse HTTP `404` au format Problem Details.
