Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Only error-log unexpected failures, not expected HTTP/validation errors
In a controller catch, skip error-level logging for thrown HttpExceptions (expected client errors) and only log genuine unexpected failures, then re-throw.
Bad example
| 1 | try { |
| 2 | const result = await this.service.createTransaction(ctx, dto); |
| 3 | return serialize(ResponseDto, result); |
| 4 | } catch (error) { |
| 5 | // Logs every failure as error, including 400-level validation errors |
| 6 | // the service already logged and intentionally threw. |
| 7 | this.logger.error( |
| 8 | `Failed to create transaction for ${id}`, |
| 9 | JSON.stringify({ body: dto, error: error instanceof Error ? error.message : error }), |
| 10 | ); |
| 11 | throw error; |
| 12 | } |
Explanation (EN)
Expected client errors (e.g. validation HttpExceptions) get logged twice — once by the service, once here as error — flooding error logs with non-actionable noise and masking real failures.
Objašnjenje (HR)
Ocekivane klijentske greske (npr. validacijski HttpException) loggiraju se dvaput — jednom u servisu, jednom ovdje kao error — sto zatrpava error logove neakcijskim sumom i prikriva stvarne kvarove.
Good example
| 1 | try { |
| 2 | const result = await this.service.createTransaction(ctx, dto); |
| 3 | return serialize(ResponseDto, result); |
| 4 | } catch (error) { |
| 5 | // Only log truly unexpected failures; let expected HttpExceptions through. |
| 6 | if (!(error instanceof HttpException)) { |
| 7 | this.logger.error( |
| 8 | `Failed to create transaction for ${id}`, |
| 9 | JSON.stringify({ body: dto, error: error instanceof Error ? error.stack : error }), |
| 10 | ); |
| 11 | } |
| 12 | throw error; |
| 13 | } |
Explanation (EN)
Gating the error log on `!(error instanceof HttpException)` keeps error-level logs reserved for unexpected internal failures, while expected client errors propagate silently to the framework's exception handler.
Objašnjenje (HR)
Uvjetovanje error loga s `!(error instanceof HttpException)` cuva error razinu za neocekivane interne kvarove, dok se ocekivane klijentske greske tiho propagiraju do framework-ovog rukovatelja iznimkama.
Exceptions / Tradeoffs (EN)
If you do want an audit trail of client errors, log them at a lower level (debug/info) rather than error, so error dashboards stay clean.
Iznimke / Tradeoffi (HR)
Ako zelis trag klijentskih gresaka, loggiraj ih na nizoj razini (debug/info) umjesto error, kako bi error nadzorne ploce ostale ciste.