| | 11 | |
| | 12 | |
| | 13 | == OMERO.web error Handling == |
| | 14 | |
| | 15 | Django comes with some nice error handling functionality. We have customised this and |
| | 16 | also provided some client-side error handling in Javascript to deal with errors in AJAX requests. |
| | 17 | This javascript can be found in the ..?...js code which should be included in all pages that require this functionality. |
| | 18 | Errors are handled as follows: |
| | 19 | - 404 Simply display a 404 message to the user |
| | 20 | - 403 This is 'permission denied' which probably means the user needs to login to the server (E.g. session may have timed out). The page is refreshed which will redirect the user to login page. |
| | 21 | - 500 Server error. We display a feedback form for the user to submit details of the error to our QA system - POSTs to "qa.openmicroscopy.org.uk:80". This url is configurable in settings.py. |
| | 22 | |
| | 23 | |
| | 24 | There are various scenarios for handling errors, depending on whether you handle them yourself, or allow Django to handle them, |
| | 25 | whether you are in Debug mode or not, and whether the http request is AJAX. |
| | 26 | |
| | 27 | |
| | 28 | == Default behavior == |
| | 29 | If you do not write any error handling (or if the error occurs outside a try/except block etc... |
| | 30 | |
| | 31 | === With Debug: True (during development) === |
| | 32 | |
| | 33 | Django will return an html page describing the error, with various parameters, stack trace etc. |
| | 34 | If the request was AJAX, and you have our javascript code on your page then the error will be handled as described (see above). |
| | 35 | NB: With Debug True, 500 errors will be returned as html pages by Django but these will not be rendered as html in our feedback form. |
| | 36 | You can use developer tools on your browser (E.g. Firebug on Firefox) to see various errors and open the request in a new tab |
| | 37 | to display the full debug info as html. |
| | 38 | |
| | 39 | === With Debug: False (in production) === |
| | 40 | Django will use it's internal error handling to produce standard 404, 500 error pages. We have customised |
| | 41 | this behaviour to display our own error pages. The 500 error page allows you to submit the error as |
| | 42 | feedback to our QA system. If the request is AJAX, we return the stack trace is displayed in a dialog |
| | 43 | which also allows the error to be submitted to QA. |
| | 44 | |
| | 45 | |
| | 46 | == Custom Error handling == |
| | 47 | If you want to handle certain exceptions in particular ways, E.g. display a particular message to the user, log particular details etc, |
| | 48 | you should use appropriate try/except statements. |
| | 49 | For more info on logging, see [link] |
| | 50 | For 500 errors, it is a good idea to always return the stack trace along with any message you want the user to see. |
| | 51 | This allows users to inspect or submit the error for diagnosis etc. |
| | 52 | {{{ |
| | 53 | try: |
| | 54 | # something bad happens |
| | 55 | except: |
| | 56 | logger.error(traceback.format_exc()) # log the stack trace |
| | 57 | err_msg = "Something bad happened! \n \n%s" % traceback.format_exc() # message AND stack trace |
| | 58 | return HttpResponseServerError(err_msg) |
| | 59 | }}} |
| | 60 | |
| | 61 | |
