solution-oriented-error-handling.json

{
  "alias": "video/3029/solution-oriented-error-handling",
  "category": "EuroPython 2014",
  "copyright_text": "http://creativecommons.org/licenses/by/3.0/",
  "description": "Traditionally error handling is regarded an annoyance by developers\nbecause it removes the focus from the already difficult enough\nproductive parts of the code to parts that ideally will never be called.\nAnd even if, end users seem to be ignore the error messages and just\nclick \"Ok\" or call the help desk.\n\nSolution oriented error handling uses Python's existing\ntry/catch/finally idiom, with statement, assert statement and exception\nhierarchy in a way that keeps the code clean and easy to maintain. It\ngives a clear distinction between errors that can be solved by the end\nuser, the system administrator and the developer. Naming conventions and\na simple set of coding guidelines ensure that helpful error messages can\nbe easily derived from the code.\n\nMost code examples work with Python 2.6+ and Python 3.x, on a few\noccasions minor differences are pointed out.\n\nTopics covered are:\n\n1. Introduction to error handling in Python\n\n   -  What are errors?\n   -  How to represent errors in Python\n   -  Detecting errors\n   -  Delegating errors to the caller\n   -  clean resource management\n\n2. Principles of solution oriented error handling\n\n   -  responsibilities between user, admin and developer\n   -  when to use raise or assert\n\n3. Error messages\n\n   -  What are \"good\" error messages\n   -  How to derive error messages from the source code\n   -  Adding context to the error\n   -  How to report errors to the user\n\n4. Solution oriented usage of Python's exception hierarchy\n\n   -  admins fix ``EnvironmentError``\n   -  users fix ``DataError``\n\n      -  representing ``DataError``\n      -  converting exceptions to ``DataError``\n\n   -  developers fix everything else\n   -  special Python exceptions not representing errors\n\n5. Template for a solution oriented command line application\n6. Best practices for ``raise`` and ``except``\n\n   -  When to use ``raise``?\n   -  When to use ``except``?\n\nThis talk is a translation of a German\n`talk <https://github.com/roskakori/talks/tree/master/pygraz/errorhandling>`__\ngiven at the PyGRAZ user group and in a (slightly depythonized variant)\nthe Grazer Linux Tag 2013 (`slides and\nvideo <http://glt13-programm.linuxtage.at/events/198.de.html>`__).\n",
  "duration": null,
  "id": 3029,
  "language": "eng",
  "quality_notes": "",
  "recorded": "2014-07-22",
  "related_urls": [
    "http://glt13-programm.linuxtage.at/events/198.de.html",
    "https://github.com/roskakori/talks/tree/master/pygraz/errorhandling"
  ],
  "slug": "solution-oriented-error-handling",
  "speakers": [
    "Thomas Aglassinger"
  ],
  "summary": "This talk shows how to use Python's built in error handling mechanisms\nto keep the productive code clean, derive error messages helpful for the\nuser directly from the code and release ressources properly.\n",
  "tags": [],
  "thumbnail_url": "https://i.ytimg.com/vi/kT34QMil-FQ/hqdefault.jpg",
  "title": "Solution oriented error handling",
  "videos": [
    {
      "length": 0,
      "type": "youtube",
      "url": "https://www.youtube.com/watch?v=kT34QMil-FQ"
    }
  ]
}