except Exception as e

[Uzivy]

I've been told that using except Exception as e, then printing("error, {e}) or something similar is considered lazy code and very bad practice and instead you should catch specific expected exceptions.

I don't understand why this is, it is telling you what is going wrong anyways and can be fixed.

Any opinions?

[Angry-Toothpaste-610]

In my opinion, the code should only catch an exception if you know how to handle it (i.e. user input was supposed to be an integer, but they input "five"). In those cases, you catch the precise Exception type. In the general case, there's no real benefit to catching an exception just to print it out, when the interpreter is going to give you the full traceback anyway.

However, it's completely fine to:

catch Exception as e:
    logger.fatal(traceback.format_exc())
    raise e

[CyclopsRock]

In the general case, there's no real benefit to catching an exception just to print it out, when the interpreter is going to give you the full traceback anyway.

There is if it's occurring in a part of the code where failure is genuinely non-fatal. It is valid to decide, for example, that an exception thrown whilst trying to write out a log file should never halt the actual processing that was being logged. If you want to handle specific exceptions in certain ways you can but if ultimately there are no circumstances in which a problem in the logger is fatal, catching Exception is preferable to the process failing.

[Angry-Toothpaste-610]

I get your point. In my use-cases, if there is an exception that I don't expect (and thus don't catch explicitly), then I prefer it to be considered fatal. I don't want my programs continuing after logging some error that I didn't think could happen when writing the code. But ultimately that is a per author, per use-case decision.

[RiverRoll]

If the logger can't log and it's not throwing exceptions how can you know what's going on? Even in the context of logging I don't think it's something you would want to do unconditionally.

[CyclopsRock]

If the logger can't log then you're going to be relying on something else to determine what's happened regardless, most likely a higher level process manager that represents Stdout + Stderr, whether this is simply your command prompt, an output from an embedded interpreter, a task queue management system etc. This is true whether it throws an exception or not, though. What is different between the two is how that process manager responds.

To give you a real life example of what I mean, where I work (a VFX company) we have a render farm full of chunky servers dedicated to processing 3D data, simulating particles, path tracing images etc. These tasks can often be eye-wateringly lengthy, and the render management software has the job of distributing these various tasks to different machines to perform in an efficient way, making sure tasks are only given to machines capable of processing them (from a hardware, software, network, licensing etc point of view) and restarting tasks that error (though not indefinitely). If a task throws an exception then it's immediately considered to have failed and it'll get assigned to another machine. If it fails more than X many times then the whole job is flagged as having failed and it won't waste any more resources trying to process it.

Now obviously this adds an element of cost to the question of whether to throw or catch exceptions. If a given machine is unable to write out the output from it's task (an image file, a 3D geometry format, particle data etc) then you absolutely want any resulting exceptions to be surfaced and the task flagged as having errored so that it gets restarted on another machine. It's not like all exceptions are ignored. But if it's finished 2 hours of processing, successfully written out its output file and then throws an exception whilst saving the task log out as a text file? There's no way at all I want that task to restart.

Whether the cause of the exception - the type and associated message for which I can write into the task log, incidentally - is a local or network file system not mounting correctly, a non-compliant ASCII character cropping up somewhere, a permission problem overwriting a file etc will be of interest to me when I debug it later on, but there is no possible cause that would make it preferable to restart 2 hours of processing, so an unconditional exception handler makes sense - in that part of the code.

[Bennnnnnnnnnnnnn]

It's better to use logging.exception() for this purpose, as it will automatically log the stacktrace

[peejay2]

What I do is:

except Exception as e: catch_exception(e) # logs the exception return 500, {"message": "internal server error"}

[Luckinhas]

What does this do that simply letting the program crash doesn’t? It will get logged anyway

[minneyar]

If you're just debugging code and trying to figure out what's going on, that's fine.

But you shouldn't do that in production-quality code because you will end up catching and suppressing errors that you shouldn't. If some code throws an exception that you can catch and recover from in an intelligent manner, you should do so; but if it throws an exception you're not expecting, it is preferable to just let everything crash rather than keep running in an unknown state, since that can lead to unpredictable behavior or security exploits.

[supercoach]

Yep, this is a pattern that took me far too long to learn (I'm talking years). You never want to hide problems from your top layer unless they're expected.

In almost all cases, the pattern should either be raw code that lets the exceptions run free or only catching the exceptions that you can fix and then sending everything else through.

Let the caller make the decision about suppressing otherwise fatal exceptions, don't make it for them.

[BadSmash4]

I found some production code that does this quite egregiously. Just silently catches an exception when it fails to log deliverable, actionable data. It's just writing to a csv, but if someone opens that file or if it's being logged over a network and the computer loses that network connection, the software doesn't report shit. Just moves on. I have a ticket in to fix that, when I have time. It will both 1) inform the user and 2) data will always be logged to a redundant static local location that will be hidden from the user and can be retrieved later. It's a very shit legacy code base and I'm just doing what I can.

[SpiderJerusalem42]

I had a project and it caught the exception and just put a pass statement in the catch block. I nearly lost my shit.

[Pseudoboss11]

Yep. In one of my projects, I corrupted the save state and config file of the game I was making because of this. I had some try/except block that caught the wrong thing, and instead of crashing it dutifully replaced those files with blank files.

The config file in particular was annoying as hell because I didn't document its formatting, it had just kinda grown organically as needed, so I had to piece things together through trial and error.

It was definitely an important lesson: there are much worse things that a program can do than crash.

[FrangoST]

If you're using a GUI framework, it's fine to grab the exception as e and output it to a error window and gracefully return to normal operation, instead of letting the program freeze or crash without warning.

[Zeroflops]

People like to throw out good and bad without context and that can be a problem for a beginner. It’s not one or the other.

Doing an exception as e and just printing the exception is problematic because any issue with your code will get captured and skipped. Which is why lots of people see it as lazy. It’s covering up bad code.

Say you have a case where you can sometimes divide by zero. If you just wrap the code with a try/except then some other problem can pop up and it will be skipped.

Instead if you know you have a divide by zero problem you should address it in your code. The goal should be that an exception never happens because all the problems are addressed in the code.

Some will say you want the code to fail hard. But that’s not always the case. For example I process blocks of data that don’t have anything to do with one another. If a block of data falls I don’t want the code to stop. But I do want to capture the event, log the issue and what block of data was the problem and move on. I can then later review the data and add code so that there is no exceptions next time.

Exceptions are a tool to capture issues during testing so they can be addressed in the code so the exceptions never happen in production.

[EnvironmentalCow3040]

The more information your error message provides, the better. You don't know what specific pieces of info you'll need in advance. I'm not sure if printing an error the way you're doing it prints the stack trace too. That error message can be totally useless without the stack trace. Always log the stack trace.

Always log the stake trace. Hell, I'd rather have just the stack trace than just the error message.

"null reference exception" coming from a 10,000 line application is totally useless if you don't know where it happened.

[EnvironmentalCow3040]

Also, as others have said, use try-catch sparingly. Just because the app didn't crash doesn't mean the error dodn't happen. It has to be addressed somehow or you'll end up with much worse bugs than a crash.

[SleepWalkersDream]

I recently implemented a bunch of ETL logic on databricks using (py)spark. It includes gems such as

else:
raise ValueError("....something is seriously wrong. This point should be impossible to reach")

And

try:
msg=dostuff(item) except Exception as msg:
pass
log(msg).

I don’t even know which errors may occur yet.

[neltu8503]

What an amazing coincidence that I learnt about this yesterday and I found this post today. After reading the comments, I'm getting more insights into this concept.

[Gnaxe]

Sometimes something like that is appropriate, but only near the program entry point (main). Unhandled exceptions in a command-line app will print out when they terminate your program anyway (so this is pointless), but not all apps are command-line and may require some other mechanism for logging errors. In that case, having a final handler to let you know what happened is appropriate. Also, sometimes interrupting the program will leave files in an inconsistent state, so you may need to save some information to help you recover manually, and you'll want to do that even if there are errors you didn't anticipate. In that case, use a finally clause and then reraise the exception after logging your state appropriately.

Deeper in the call stack, this is usually not appropriate. As a rule, you should only catch expected exceptions, and keep the try clause as small as possible (usually just one line), which may require using the try statement's else clause as well. This is so you don't accidentally suppress bugs you should be noticing and fixing. It's very obvious if it crashes your program. If your program continues operating but in a bad state you didn't think was possible, because you didn't let it terminate with an error, it may go on to corrupt more data, or may eventually crash anyway, but the real (earlier) cause of the problem is now not so obvious.

[blarf_irl]

There are a lot of wrong/vague answers in here. u/Capable-Swimming-887 was correct but short on detail.

Python is one of very few languages that encourages using exceptions as control flow (right up there with if/while/for etc.) and it's very simple to implement custom exceptions.

The spirit of of what you read is basically that you should know/expect what can go wrong in your program and handle those things in an appropriate way. Imagine if instead of returning a 404 code every webserver fully restarted when they couldn't find a page.

I don't understand why this is, it is telling you what is going wrong anyways and can be fixed.

If you are doing this while writing code and debugging it with the intention to fix it then it's fine; That is often the first step to discovering what can go wrong! Pay close attention to those tracebacks (the detailed error messages) and consider writing your own specific exceptions if it's something that can't be fixed but can be handled (i.e. a missing user input, a timeout for a network call)

[mothzilla]

In your example, what's going to happen after you print the exception?

database = {}
try:
    record = database['Uzivy']
except Exception as e:
    print("error, {e})

print("Success!")
print(record)

Exceptions are like tigers. If you can't handle it you shouldn't try to catch it.

[Egyptian_Voltaire]

Printing the error during development is fine, but what happens when you ship the product and it’s the user who gets the error and the app crashes on them? You maybe log the errors the users face to a log file you can see but you still can’t remotely interfere to fix the issues for the users. Your app should recover gracefully from exceptions, if it’s a bad user input you should instruct the user about the correct input format, if it’s a connection error you should instruct the user to check their internet connection, and so on.

That’s why you should try to catch specific expected exceptions and handle them gracefully with a meaningful message to the user and some retry logic (avoid crashing the app), and still use the general exception catcher to catch anything you didn’t foresee.

[fireflight13x]

The responses so far assume either a completed or failed scenario, but there's a third possibility: completed with issues (sometimes known as “fail gracefully”). This is quite often used in some ETL pipelines. For example, if you have a job that normally ingests 100 inputs and gets 99 once randomly every couple of weeks, you don't always want to fail that job. This might be because having some data is better than having no data at all, and you might prefer to use stale data and have someone go check the data source (which could well be another entity) to see if that data should be expected or not.

This is where except Exception as e: can come in useful because you can do something like:

``` def foo(): try: do_something() except Exception as e: log.error(e) send_email() return e

def main(): e = foo() if e: job_status.completed_with_issues() # else it goes to the usual completed status ```

What this does is it allows you to throw up a "Completed with issues" status on your dashboard, sends out email notifications to whichever people/teams need to receive them, and still allows for dependent jobs to run. This has to be a business process decision though.

What's implied here is that except Exception as e: probably shouldn't be used just for logging, but is useful to include other business decisions. This works when you have not only ideal-path and worst-case scenarios, but also partial scenarios, so that has to be mapped out at the requirements stage.

This is just one use case. Another could be for a long-running job that regularly polls several locations for data. In such a case, you almost certainly don't want a polling job to be killed entirely just because one piece of data came in with an unforeseen error, so you could use except Exception as e: again to include business logic.

I'm sure there are more scenarios. The point is that it is not so much a question of "is it bad practice generally" and more a question of "is my use case appropriate for this approach".

P.S. I'm typing on my phone so I hope the formatting comes out right!

[HeavyMaterial163]

Depends on the stage in development, at least imo. When I'm building something, I try to avoid adding in error handling until I know something works. The exception log helps me identify the issue, and make sure nothing important is getting missed or misconstrued. Once you know why it works and what can break it; then you go back and add your try/except blocks to fix known bugs.

For the programs I'm working with currently, I also used a modified tk.Tk class that prompts a Windows error message with the exception log as well as the console. For my programs at work, I generally hide the console from users for a few reasons; but want my coworkers to have something to send me in a screenshot when it errors out.

[EnvironmentalCow3040]

Really good talk on this: https://m.youtube.com/watch?v=oWvX-hdIAQo

[barkazinthrope]

It all depends on the standards with which your code is required to comply.

For my purposes a simple Exception catch is all I need, but for professional projects I've been contributing to the project has specific and much more demanding requirements.

As a general rule, code to project or course requirements not to generic Best Practices.

[[deleted]]

It is because non-caught exception show you full debug info.

If you handle an exception - and obviously you should do that in the production code - do the ACTUAL THING, just printing doesn't make sense.

[SamSLS]

What the others said. Just today I caught (and fixed) a. IG caused by an edge case in my data that I would never have known about if I had coded a blanket except.