Some lines of code - mostly function and method calls - are "risky", in the sense that under certain circumstances they aren't guaranteed to succeed. The most risky functions are those that rely on another system succeeding at a task. For instance, if you ask a remote server for a response, you're relying on the remote server to successfully respond. What if it doesn't? What if I've reached over and turned the power off just as you've sent the request? What if the internet stops working at that time? A function relates input to output - the input are the function's parameters, and the output is the return value. But that makes the assumption that a function always yields the return value demanded by its arguments. How does a function indicate when it won't be possible to return that value? That's what exceptions are for - they're a way for the function to terminate in an "exceptional" way, that is, a way that is an exception to the normal operation of the function. Since the exception isn't a return value of the function, but a different and special way for the function to terminate, we use a different term to describe yielding an exception - we say that a function throws an exception. This should bring to mind the idea of "throwing your back out" or "my car threw a piston rod", in the sense of how it indicates something has gone wrong. In other languages, functions that can throw exceptions have to declare that they do, which puts the risks of calling the function up-front but it also requires that when you call those functions, you make some decisions about what to do with exceptions. This is a little bit of an unreasonable expectation on new programmers so Python doesn't require either of these things, and so you should assume that a function might throw an exception if it would be reasonable for it to do so under certain circumstances. Adding two numbers isn't going to throw an exception. Making a remote procedure call on another system is going to throw different kinds of exceptions based on the myriad ways that can go wrong (the system doesn't exist, the system refuses to comply, the system doesn't know how, etc.) When you call a function and it throws an exception, if you don't immediately handle the exception, your function will terminate as well. It'll throw the exception "up" the calling chain, up to the very top level of your program where, if the exception isn't handled, it'll crash your program. This is an important safety tool because it prevents your program from continuing in an undeterminable state. If you want to try to handle the exception - it's predictable and there's some reasonable action your code can take in response, like try again in a couple of seconds or something - then you can use a "try/except" block to enclose the logic that may throw an exception, and handle it if it does. You can choose which exceptions you want to handle via declaration and you can handle different exceptions differently. Or you can handle some and not others. More on reddit.com

how do you know all of the exceptions a function could possibly raise You don't. You should approach error handling in a way that known/common cases are "handled" and unknown/edge cases "make noise." Generally, you want to handle the known/common cases gently so the system keeps running, and let the unknown/edge cases cause the system to fail hard and fast. More on reddit.com

It depends what you mean by "end user". If a program is meant to be used by a non-programmer (like a command-line script utility, or anything with a GUI), then absolutely, you should try to make it as user-friendly as possible (the full error traceback isn't going to be particularly useful to them). But if you're writing code that other Python programmers are going to use in their own projects, you want to stick to the conventions of error handling that everyone is used to. That then gives those other programmers the control to handle/display the error however they see fit, depending on who their end users are going to be. More on reddit.com

I like Go but this error handling repeat itself everywhere. Prefer the exceptions More on reddit.com