Changes between Version 30 and Version 31 of DeveloperGuidelines/CodeConventions

Timestamp:

10/09/13 20:00:17 (11 years ago)

Author:

Dominic König

Comment:

--

DeveloperGuidelines/CodeConventions

@@ -128 +128 @@
   - You should never raise an exception for '''Validation Errors''' - any invalid user input '''must be caught and properly reported''' back to the client (simply because users can't do anything about an exception, so it would render the functionality unusable - whilst a proper error message may help the user to correct their input). Failure to catch validation errors is always a bug.
   - '''Configuration Errors''', wherever possible, should at most issue a warning (if the invalid setting is obviously a mistake), and else get ignored and fall back to reasonable defaults. Only if there is no possible fallback action, then Configuration Errors should be treated as Runtime Errors.
-  - '''Runtime Errors''' may raise exceptions if unrecoverable (i.e. if there's no reasonable handling possible at the respective level). However, they must be caught at a higher level and properly reported back to the client in order to explain the reason and allow correction.
+  - '''Runtime Errors''' may raise exceptions if unrecoverable (i.e. if there's no reasonable handling possible at the respective level). However, if possible and in production mode, they should be caught at a higher level and properly reported back to the client in order to explain the reason and allow correction. Remember logging!
   - '''Programming Errors''' (=bugs) ''must'' lead to exceptions in order to attract immediate attention of the programmer to the bug and help them debugging. They should never be caught unless you intend to implement a plausible fallback action (and even then a warning may be appropriate in most cases).