Always catch specific exception types rather than generic `Exception` to avoid masking unexpected errors and ensure intentional error handling. This practice helps distinguish between expected failure scenarios that should be handled gracefully and unexpected errors that indicate bugs.
Always catch specific exception types rather than generic Exception
to avoid masking unexpected errors and ensure intentional error handling. This practice helps distinguish between expected failure scenarios that should be handled gracefully and unexpected errors that indicate bugs.
When handling known failure cases, catch the specific exception type that the API contract specifies. For example, when setting font variation settings which throws IllegalArgumentException
for invalid input, catch only that specific exception:
try {
fontVariationSettings = fontVariationSettingsParam
} catch (e: IllegalArgumentException) {
Log.w(TAG, "Invalid font variation settings: $fontVariationSettingsParam", e)
// Handle gracefully - continue without font variations
}
Avoid generic exception catching which can hide programming errors:
// DON'T DO THIS - masks all errors including unexpected ones
try {
fontVariationSettings = fontVariationSettingsParam
} catch (e: Exception) {
// This could hide NullPointerException, OutOfMemoryError, etc.
}
Additionally, validate inputs early to prevent crashes from edge cases, and remove unnecessary try blocks that have no catch or finally clauses as they create misleading code structure without providing error handling benefits.
Enter the URL of a public GitHub repository