{ "metadata": {}, "nbformat": 4, "nbformat_minor": 5, "cells": [ { "id": "metadata", "cell_type": "markdown", "source": "
\n\n# Python - Try & Except\n\nby [Helena Rasche](https://training.galaxyproject.org/hall-of-fame/hexylena/), [Donny Vrins](https://training.galaxyproject.org/hall-of-fame/dirowa/), [Bazante Sanders](https://training.galaxyproject.org/hall-of-fame/bazante1/)\n\nCC-BY licensed content from the [Galaxy Training Network](https://training.galaxyproject.org/)\n\n**Objectives**\n\n- How do I try to execute code, knowing it might fail?\n- What are some situations where this is important?\n- How can I write my own exceptions.\n\n**Objectives**\n\n- catch an exception\n- raise your own exception\n\n**Time Estimation: 20M**\n
\n", "metadata": { "editable": false, "collapsed": false } }, { "id": "cell-0", "source": "

Try/except are a construct in Python used to catch a potential exception. Sometimes things go wrong in your code! Or in someone else’s code in a module. Sometimes some errors might be expected like when you try and read a user supplied file, maybe it isn’t available because they’ve specified the wrong path.

\n
\n
Agenda
\n

In this tutorial, we will cover:

\n
    \n
  1. Raise
    2. \n
\n
\n

Raise

\n

When you’re writing code, sometimes there are errors you might need to handle:

\n\n

Using try/excepts allow you to:

\n\n

For instance, returning to the mean() function example, what should mean([]) return for a hypothetical mean function that calculates the average of a list of numbers. Should it return 0? It probably should return an error. Let’s look at some example code:

\n", "cell_type": "markdown", "metadata": { "editable": false, "collapsed": false } }, { "id": "cell-1", "source": [ "def mean(numbers):\n", " return sum(numbers) / len(numbers)\n", "\n", "mean([1, 2, 3])\n", "mean([])" ], "cell_type": "code", "execution_count": null, "outputs": [], "metadata": { "attributes": { "classes": [ "> " ], "id": "" } } }, { "id": "cell-2", "source": "

This raises a ZeroDivisionError but we can make this a more friendly error message by raising our own exception.

\n", "cell_type": "markdown", "metadata": { "editable": false, "collapsed": false } }, { "id": "cell-3", "source": [ "def mean(numbers):\n", " if not numbers:\n", " raise ValueError(\"You are calculating the mean of an empty list, which is not possible.\")\n", " return sum(numbers) / len(numbers)\n", "\n", "mean([1, 2, 3])\n", "mean([])" ], "cell_type": "code", "execution_count": null, "outputs": [], "metadata": { "attributes": { "classes": [ "> " ], "id": "" } } }, { "id": "cell-4", "source": "
\n
\n

There are loads of different types of exception codes! The python documentation has a large list of exceptions and some descriptions for when or why those exceptions might be raised.

\n
\n

Now we get a much more useful error message from the function! Using raise is especially important for library authors, people writing python modules that we all use. If they provide useful error messages, it helps you as an end user understand what’s happening.

\n

Try & Except

\n

Let’s look at how you would handle one of these exceptions, we’ll continue with the mean() example above.

\n", "cell_type": "markdown", "metadata": { "editable": false, "collapsed": false } }, { "id": "cell-5", "source": [ "numbers = []\n", "try:\n", " result = mean(numbers)\n", " print(f\"Result is {result}\")\n", "except ValueError:\n", " print(\"We cannot calculate the mean\")" ], "cell_type": "code", "execution_count": null, "outputs": [], "metadata": { "attributes": { "classes": [ "> " ], "id": "" } } }, { "id": "cell-6", "source": "

Here we use try: to setup a new block, and this code is tried, Python attempts to execute it. Below are one or more except: blocks which catch specific errors. Here we have specifically said we know a ValueError can happen, and decided to handle it.

\n

Or for another example, accessing a user supplied file. Oftentimes users will call your program and supply a non-existent, or inacessible file. Here you can use multiple except blocks to catch all of those potential errors.

\n", "cell_type": "markdown", "metadata": { "editable": false, "collapsed": false } }, { "id": "cell-7", "source": [ "user_supplied_file = 'does-not-exist.txt'\n", "try:\n", " open(user_supplied_file, 'r')\n", "except FileNotFoundError:\n", " print(f\"The path you supplied ({user_supplied_file}) doesn't exist, please double check it!\")\n", "except PermissionError:\n", " print(f\"You supplied a valid file, but it is unreadable. Try changing it's permissions with `chmod +r {user_supplied_file}`\")" ], "cell_type": "code", "execution_count": null, "outputs": [], "metadata": { "attributes": { "classes": [ "> " ], "id": "" } } }, { "id": "cell-8", "source": "

Failing to open a file raises a FileNotFoundError which indicates the file isn’t available, and PermissionError indicates that a file is unreadable. However in practice, sometimes you’ll see something like this:

\n
# Bad!\ntry:\n    doSomething()\nexcept:\n    print(\"error\")\n
\n

This is called a bare exception, and will catch any exception, compared with except ValueError which only catches value errors. People consider this generally a bad idea, termed code smell. (Because it smells (appears) bad!)

\n

Finally

\n

The last portion of the try:/except: block is finally:, a third block which lets us do cleanup. It’s often very nice to your users that if your program fails halfway through, that you cleanup after yourself.

\n", "cell_type": "markdown", "metadata": { "editable": false, "collapsed": false } }, { "id": "cell-9", "source": [ "import os\n", "\n", "try:\n", " with open('gene_query.fa', 'w') as handle:\n", " handle.write(\">some fasta sequence we want to search against a database\")\n", "\n", " # runQuery('gene_query.fa')\n", "\n", " # But here we have an error! Something goes wrong!\n", " 1 / 0\n", "except:\n", " # And now our results are invalid.\n", " print(\"Something went wrong! Oh no! Check your inputs.\")\n", "finally:\n", " # So we should cleanup this temporary file we created, so it doesn't cause\n", " # problems or distract the user from the results file.\n", " # This function will delete a file from your computer:\n", " os.remove('gene_query.fa')" ], "cell_type": "code", "execution_count": null, "outputs": [], "metadata": { "attributes": { "classes": [ "> " ], "id": "" } } }, { "id": "cell-10", "source": "

Fallback

\n

Sometimes we can use try/except to have a fallback option. Consider the pseudocode below:

\n
try:\n    runBlast()\nexcept BlastNotAvailable:\n    try:\n        runBLAT()\n    except BLATnotAvailable:\n        print(\"Neither Blast nor BLAT were available.\")\n
\n

Sometimes you have a fallback option, some other tool you can use in its place. When that’s possible, you can use try and except to handle those cases and work around potential issues. But this isn’t always the case, sometimes you just need to print your error message and stop executing code.

\n", "cell_type": "markdown", "metadata": { "editable": false, "collapsed": false } }, { "cell_type": "markdown", "id": "final-ending-cell", "metadata": { "editable": false, "collapsed": false }, "source": [ "# Key Points\n\n", "- raise lets your raise your own `Exception`s\n", "- This is mostly used by library authors (which you might become!)\n", "- Use `try`/`except` to catch expected errors and work around them (if possible)\n", "- finally lets you cleanup your temporary files, if you created some.\n", "\n# Congratulations on successfully completing this tutorial!\n\n", "Please [fill out the feedback on the GTN website](https://training.galaxyproject.org/training-material/topics/data-science/tutorials/python-exceptions/tutorial.html#feedback) and check there for further resources!\n" ] } ] }