Changes between Version 30 and Version 31 of DeveloperGuidelines/CodeConventions


Ignore:
Timestamp:
10/09/13 20:00:17 (8 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/CodeConventions

    v30 v31  
    128128  - 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.
    129129  - '''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.
    130   - '''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.
     130  - '''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!
    131131  - '''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).
    132132