Changes between Version 29 and Version 30 of DeveloperGuidelines/CodeConventions


Ignore:
Timestamp:
10/09/13 19:43:33 (8 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelines/CodeConventions

    v29 v30  
    121121    f.close()
    122122}}}
    123  
    124123
     124When should you raise Exceptions, anyway?
     125
     126If it is not possible to continue with the respective processing because there can not be any plausible result, then the necessary consequences highly depend on the cause:
     127
     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.
     129  - '''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.
     131  - '''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).
     132
     133Eden is an unsupervised server system, so you must have very good reasons to let it crash.
     134
     135Remember that any uncaught exception leads to a HTTP 500 status with error ticket - and an HTTP 500 status in Eden is a bug by definition. Users can't do anything about error tickets, so the only legitimate reason to raise an uncaught exception in Eden is that you are 100% sure that the error condition leading to the exception is caused by a bug.
    125136=== Nulls ===
    126137Nulls make code much more complicated by introducing special cases that require special null-checking logic in every client, making code harder to understand and maintain. They often and easily cause hard-to-diagnose errors.