Unit
- Error classification: Errors are categorized by origin (syntax, runtime, logic) and impact (fatal, recoverable, informational). Syntax errors are caught at compile time in statically typed languages, while runtime errors occur during execution. Logic errors produce incorrect output without crashing the program. Understanding these classes helps prioritize debugging efforts and appropriate response strategies.
- Severity levels: Most systems adopt a severity scale (critical, high, medium, low) to rank errors by business impact. Critical errors cause complete service outage or data loss. High errors affect a subset of users or degrade core functionality. Medium errors are non-critical but should be addressed. Low errors are cosmetic or minor annoyances.
- Error vs. exception: Errors typically represent unrecoverable conditions (out-of-memory), while exceptions are manageable via handling. In languages like Java,
Errorclasses are not meant to be caught;Exceptionclasses are. Python usesBaseExceptionfor system-exiting events andExceptionfor application-level issues. - Common error patterns: Null reference errors, off-by-one indexing, file not found, network timeouts, and database deadlocks appear frequently. Recognizing these patterns speeds up diagnosis. For example, a
NullPointerExceptionoften indicates missing initialization or improper conditional checks. - Operational vs. development errors: Development errors occur pre-deployment (compile, test), while operational errors surface in production (resource exhaustion, configuration drift). Each requires different tooling. Developers rely on debuggers and logs; operations teams use monitoring and alerting.
- Error propagation: Errors can cascade: a failed database connection may trigger multiple downstream service failures. Understanding dependency chains helps isolate root causes. Tools like distributed tracing reveal path-specific error origins.
- Error reproduction: The first step in diagnosis is reproducing the error consistently. Techniques include isolating inputs, running in a controlled environment, and using similar data profiles. Reproducibility often depends on capturing full context (state, logs, configuration).
- Error budgets and SLOs: In Site Reliability Engineering, error budgets define acceptable failure rates. Teams track error rates against service level objectives (SLOs). Exceeding the budget triggers prioritized remediation. This metric-driven approach aligns error diagnosis with business priorities.
Code Example
Python
def divide_numbers(a, b):
try:
result = a / b
except ZeroDivisionError as e:
log_error('division by zero: {}'.format(e))
return None
except TypeError as e:
log_error('type mismatch: {}'.format(e))
return None
else:
log_info('division succeeded: {} / {} = {}'.format(a, b, result))
return result
finally:
cleanup_resources()The function attempts division, catching two specific exception types: ZeroDivisionError and TypeError. The else block runs only on success, and finally ensures cleanup. This pattern classifies errors by type and severity, logging each appropriately.
Security Consideration
MEDIUM RISK
Vulnerability: Information leakage through error messages. Detailed error messages may expose internal paths, stack traces, or database schemas to attackers.
Mitigation: Log detailed errors internally but return generic messages to users. Use structured logging to separate public-facing output from internal diagnostic details.
Reference: OWASP Top 10 A01:2021 - Broken Access Control (exposure of internal details)
System Architecture
Pattern: Layered Error Handling
Components:
- Application Layer: Catches exceptions from business logic, wraps them in custom exceptions with severity codes.
- Service Layer: Intercepts exceptions from multiple services, correlates them using request IDs.
- Observability Layer: Aggregates errors into a centralized logging system (ELK, Splunk), attaches severity labels.
- Alerting Layer: Routes high-severity errors to on-call teams via pager systems; low-severity errors go to dashboards.
Quick Revision
- Errors are classified by origin (syntax, runtime, logic) and severity (critical, high, medium, low).
- Severity scales guide prioritization of debugging and incident response.
- Common error patterns (null references, network timeouts) recur across systems; pattern recognition speeds diagnosis.
- Error propagation and cascading failures can be traced via dependency graphs and distributed tracing.
- Reproducing errors consistently requires capturing full context: state, logs, configuration.