It makes sense to ask if we are catching too many exceptions or too few.īecause this is all explicit, it is possible for someone to read the code and understand which exceptional conditions are recoverable. It makes sense to question why this is the right place to silence, and potentially recover from, the exception. This explicitness means that the except line is visible in code reviews. This means errors can be explicitly silenced. Python allows us to catch exceptions with except. We might anticipate some of the lines in a file are misformatted and want to handle those in a special way, maybe by putting them in a "lines to be looked at by a human" file, instead of crashing the entire program. Unless explicitly silenced.Įxceptions sometimes need to be explicitly caught. In either case, the loud failure is better than a hidden, "missing" value, infecting the program's valid data with None, until it is used somewhere and an error message says " None does not have method split," which you probably already knew.
It might mean that the program's logic is faulty. The failure might mean that a necessary condition for the program was not met, and human intervention is needed.
It will skip past the returned_value = call_to_function(parameter) line and go up the stack, potentially crashing the program.Ī crash is straightforward to debug: there is a stack trace indicating the problem as well as the call stack. The raised exception will never look like a possible value. The principle here is that if a function cannot accomplish its contract, it should "fail loudly": raise an exception. Special cases arent special enough to break the rules. Sometimes, it is even a valid return value. The Zen of Python, by Tim Peters Beautiful is better than ugly. A None is silent: it looks like a value and can be put in a variable and passed around. The C2 wiki defines the Samurai Principle: "return victorious, or not at all." In Pythonic terms, it encourages eschewing sentinel values, such as returning None or -1 to indicate an inability to complete the task, in favor of raising exceptions. Smalltalk's ideas influenced many object-oriented languages, Python included. These are principles that mostly came out of a Smalltalk programming community. Errors should never pass silently…īefore the Zen of Python was a twinkle in Tim Peters' eye, before Wikipedia became informally known as "wiki," the first WikiWiki site, C2, existed as a trove of programming guidelines. The Zen offers Python's meditation on the topic. Since "exception conditions," by nature, are the least tested but occur with unpleasant frequency, correctly handling them can often distinguish a system that horror stories are told about to a system that "just works."įrom Java's checked exceptions through Erlang's fault isolation to Haskell's Maybe, different languages have remarkably different attitudes to error handling. That could be because the stakes are high: mishandled error values can bring down even the largest systems. Transcript Discussion You can access the Zen of Python with the following import: > import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Handling "exceptional conditions" is one of the most debated issues in programming.
0 kommentar(er)
