convore.json/groups/python/are-catch-all-exceptions-ever-ok/messages.json

[{"user_id": 13916, "stars": [], "topic_id": 14089, "date_created": 1300647470.8450069, "message": "that is exactly the reason you'd do a catch all, for some context where you'd like to mark an operation as \"failed\" in some way (in your case logging it) and have the program continue", "group_id": 292, "id": 393191}, {"user_id": 1822, "stars": [], "topic_id": 14089, "date_created": 1300646998.6265869, "message": "I have a case where I'm using a except Exception: at the end of a try", "group_id": 292, "id": 393160}, {"user_id": 1822, "stars": [], "topic_id": 14089, "date_created": 1300647246.8143151, "message": "http://docs.python.org/tutorial/errors.html#handling-exceptions\n\n(demonstrates this exact pattern if used carefully and with caution)\n\nhttp://blog.ianbicking.org/good-catch-all-exceptions.html\n\n(says its OK to do if you are re-raising)", "group_id": 292, "id": 393173}, {"user_id": 1822, "stars": [], "topic_id": 14089, "date_created": 1300647046.004395, "message": "the only thing that happens is a recording of the error somewhere and then an immediate re-raise for the calling code to handle it as it sees fit - it is not absorbed", "group_id": 292, "id": 393162}, {"user_id": 1822, "stars": [], "topic_id": 14089, "date_created": 1300647118.902102, "message": "I understand that this can be abused, but are there legitimate uses of it?", "group_id": 292, "id": 393163}, {"user_id": 1736, "stars": [], "topic_id": 14089, "date_created": 1300647455.700654, "message": "Sure, I use them frequently when I need to send back error responses over HTTP (in a specific format usually)", "group_id": 292, "id": 393189}, {"user_id": 1736, "stars": [], "topic_id": 14089, "date_created": 1300647468.0443821, "message": "A bare except is different", "group_id": 292, "id": 393190}, {"user_id": 7, "stars": [], "topic_id": 14089, "date_created": 1300653382.039, "message": "@coderanger bah +1, stupid typo, don't think I've ever actually written that :)", "group_id": 292, "id": 393690}, {"user_id": 7, "stars": [{"date_created": 1300752960.5759571, "user_id": 8391}, {"date_created": 1300775719.7855871, "user_id": 14074}, {"date_created": 1300911055.5864561, "user_id": 7376}], "topic_id": 14089, "date_created": 1300651993.1302609, "message": "except Exception, e:\n    log(e)\n    raise e", "group_id": 292, "id": 393584}, {"user_id": 7, "stars": [{"date_created": 1300752962.2890289, "user_id": 8391}], "topic_id": 14089, "date_created": 1300651996.0328259, "message": "is very acceptable", "group_id": 292, "id": 393585}, {"user_id": 1736, "stars": [{"date_created": 1300678591.6441979, "user_id": 4578}, {"date_created": 1300882323.504987, "user_id": 4937}, {"date_created": 1300974709.385977, "user_id": 20326}], "topic_id": 14089, "date_created": 1300652877.233134, "message": "@alex Ack, that is terrible, use \"raise\" not \"raise e\" or the traceback changes", "group_id": 292, "id": 393661}, {"user_id": 5639, "stars": [{"date_created": 1300655358.914921, "user_id": 7}, {"date_created": 1300657041.955791, "user_id": 4141}, {"date_created": 1300667192.739392, "user_id": 927}], "topic_id": 14089, "date_created": 1300653477.1084499, "message": "@alex also high time you started using the \"as\" keyword.", "group_id": 292, "id": 393700}, {"user_id": 3354, "stars": [{"date_created": 1300721397.518533, "user_id": 1175}, {"date_created": 1300801000.099793, "user_id": 20326}], "topic_id": 14089, "date_created": 1300705763.554621, "message": "The issue with catch-all exceptions is that they also catch things like SystemExit and KeyboardInterrupt which generally you don't want caught: hence @alex's usage.", "group_id": 292, "id": 397151}, {"user_id": 1736, "stars": [], "topic_id": 14089, "date_created": 1300727514.533829, "message": "@holdenweb Only a bare \"except:\" will catch those, \"except Exception\" is safer in that respect.", "group_id": 292, "id": 400204}, {"user_id": 22504, "stars": [], "topic_id": 14089, "date_created": 1300732662.303966, "message": "catch all exceptions are the devil and last resort. you can do all that stuff with thorough subclass exceptions that give you an idea of where things are going wrong and how frequently. unexpected errors should fail hard and be caught in qa and fuzz testing", "group_id": 292, "id": 401085}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300740195.286593, "message": "Also it's still *technically* possible to throw any object as an exception (but you have to cheat). Not sure if an \"except Exception\" will catch that case - I'll report back...", "group_id": 292, "id": 402396}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300740156.6413679, "message": "@coderanger except BaseException: will catch those too right? In earlier versions of Python (2.5 and earlier I believe) only a bare except could be used to catch string exceptions (which may happen if you're executing arbitrary user code for example) but they're now gone from the language.", "group_id": 292, "id": 402390}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300740321.762249, "message": "\"except Exception\" does indeed catch it when you raise an arbitrary object as an exception: http://paste.pocoo.org/show/357357/", "group_id": 292, "id": 402425}, {"user_id": 1736, "stars": [], "topic_id": 14089, "date_created": 1300741233.518389, "message": "@voidspace Yeah, stuff like GeneratorExit and KeyboardInterrupt inherit from BaseException instead of Exception. Also your code violates the rule that __new__ has to return something which is an instance of the class or of a subclass ;-)", "group_id": 292, "id": 402556}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300742226.3297501, "message": "@coderanger there is no rule that __new__ has to return an instance of the class or a subclass. Really, that's just not a rule.", "group_id": 292, "id": 402699}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300742270.3546491, "message": "@coderanger if __new__ *does* return an instance of the class or a subclass then __init__ is called for you by the python runtime (with the same arguments as __new__ except self instead of cls) - but you are free to return whatever you want from __new__.", "group_id": 292, "id": 402708}, {"user_id": 1736, "stars": [], "topic_id": 14089, "date_created": 1300743155.0198009, "message": "@voidspace Fine s/rule/convention/ :-P", "group_id": 292, "id": 402781}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300743380.0461049, "message": "Hah. Ok.", "group_id": 292, "id": 402805}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300745054.3923171, "message": "That code behaves different on Python 3.2 though. It segfaults...", "group_id": 292, "id": 403049}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300745055.6907871, "message": "http://paste.pocoo.org/show/357405/", "group_id": 292, "id": 403051}, {"user_id": 13916, "stars": [{"date_created": 1300754875.7118731, "user_id": 1736}], "topic_id": 14089, "date_created": 1300754851.2264011, "message": "building on my previous comment here, here's a popular task queue called Celery.   For a an application like this, an exception is *not* a failure of the application itself, just the job.   This is the kind of place you're usually doing try/except Exception.  https://github.com/ask/celery/blob/master/celery/worker/job.py#L105", "group_id": 292, "id": 404036}, {"user_id": 15977, "stars": [], "topic_id": 14089, "date_created": 1300759093.76952, "message": "right, I've done that in projects that execute arbitrary user code and need to just report the problem and move on", "group_id": 292, "id": 404368}, {"user_id": 18539, "stars": [], "topic_id": 14089, "date_created": 1300762581.3603489, "message": "bare excepts are always wrong, catchalls are great if you re-raise *or* gracefully take down the current connection (aka self.transport.loseConnection())", "group_id": 292, "id": 404640}, {"user_id": 23371, "stars": [], "topic_id": 14089, "date_created": 1300765737.0315509, "message": "I think they're fine to use at the top level of customer facing process like a web service in order to return a 500 instead of spewing a stack trace for the world to see.", "group_id": 292, "id": 404768}, {"user_id": 3354, "stars": [], "topic_id": 14089, "date_created": 1300764739.2047369, "message": "@coderanger My point exactly. The question is after all about \"catch-all\" exceptions.", "group_id": 292, "id": 404709}, {"user_id": 20326, "stars": [], "topic_id": 14089, "date_created": 1300800852.523504, "message": "@alex, No!\n\n    except Exception, e:\n        log(e)\n        raise\n\nor probably\n\n    except:\n        some_logger.exception()\n        raise\n\nNote that even this needs to be used *extremely* judiciously, within high-level code, not deep inside your program.", "group_id": 292, "id": 407094}, {"user_id": 20326, "stars": [], "topic_id": 14089, "date_created": 1300800981.5859201, "message": "@coderanger, It's a sort of false security, though, as you're stuck not catching MemoryError and AssertionError and NameError and all kinds of other stuff you don't really likely have anything sane to do in response to.", "group_id": 292, "id": 407114}, {"user_id": 21093, "stars": [], "topic_id": 14089, "date_created": 1300806042.9867041, "message": "The worst thing of all is when a catch-all handler catches and obscures something like a SyntaxError or AttributeError or AssertionError that is just a coding error and not an expected condition.  I never use NameError and similar as expected exceptions (or almost never) just to keep this distinction between expected exception (like out of disk space) and unexpected exception (a program error) clearer.  Catch-all handlers also should be disabled during development and testing (except when testing that they work properly to keep something running in the field).  The hardest things to do right is cleaning up correctly in a catch-all handler so that things can actually continue running in a reliable and correct program state.  If program state is totally messed up then a catch-all handler designed to keep something running isn't likely to do anyone much service, or might even do a lot of damage if the bad state becomes persistent.", "group_id": 292, "id": 407937}, {"user_id": 3354, "stars": [], "topic_id": 14089, "date_created": 1300832360.5906711, "message": "Al very good points.", "group_id": 292, "id": 412373}, {"user_id": 3354, "stars": [], "topic_id": 14089, "date_created": 1300832486.643043, "message": "Sorry, Stephan, can't think why I called you Al ;-)", "group_id": 292, "id": 412391}, {"user_id": 19652, "stars": [], "topic_id": 14089, "date_created": 1300910489.3477581, "message": "I have the usecase of a program where we load \"user supplied\" scripts that are written by our sysadmin team. In this case we do \"except Exception as e:\" and report on the error. We do this at two points. When the recipe is loaded (and a Syntax error could happen) and in the except block we simulate the stacktrace printing (cause our users are techsavy) and the other one is for when the code is actually run as you may see other \"runtime errors\" like a variable being looked up that does not exist.", "group_id": 292, "id": 420195}, {"user_id": 7376, "stars": [{"date_created": 1300974697.4300971, "user_id": 20326}], "topic_id": 14089, "date_created": 1300911125.739502, "message": "@alex I believe a bare raise would be better than \"raise e\"; a bare raise re-raises the error with it's own traceback; whereas raise e would appear in the traceback as if the error happened on that line.", "group_id": 292, "id": 420273}, {"user_id": 2604, "stars": [], "topic_id": 14089, "date_created": 1300911156.3190651, "message": "@ stefa", "group_id": 292, "id": 420278}, {"user_id": 141, "stars": [], "topic_id": 14089, "date_created": 1300918379.1334651, "message": "sys.excepthook is a pretty cool alternative for scripts, i didn't know about it until i saw it in http://pycon.tv/#/video/17 (at 15:00)", "group_id": 292, "id": 421338}]