Software Engineering

Long ago, doing things the fast way instead of the right way was nicknamed “technical debt” in the field of software development. However, analogies have limits.

Good tools save time and free users from repetitive tasks, but only if they’re adopted (primarily) organically….

For the last year or so, I’ve been chipping away at a side project: a weightlifting-tracking app. The ostensible purpose is to store the metrics I want and make data entry as convenient as possible, but in practice it’s mainly a way for me to become more familiar with the development of a “large” web application and the challenges that come with it.

Rust reminds me a lot of Go. Both languages eschewed exception-style error handling, a feature present in almost every language that’s popular in industry. However, the idioms they use instead are very different.

This post is a followup to my article The Basics of Exceptions in Python, but should make sense on its own as long as you are familiar with raise and try/except.

Let’s cover a few more advanced aspects of the Python exception system. We’ll move a bit faster and talk at a higher level than we did in the last post.

Topics we’ll hit:

• More Python Built-in Exceptions
• User-defined Exception Classes
• Finally Blocks
• Keeping try Blocks Small

This post was originally meant to be a small part of my discussion of the Go programming language (coming soon) as a way of drawing contrast between Python and Go, but turned out to be extensive enough to justify its own post.

Python’s model of exceptions is quite similar to that of other popular object-oriented languages like Ruby, JavaScript, and Java¹. Errors flow differently than regular data; if not “handled”, they rise up through the entire function stack and crash the program. Developers are encouraged to write code to anticipate those exceptions, handle them before everything explodes, and change the logic flow of the program accordingly.

What exactly needs to be done in that “handling” step typically depends on what went wrong, and so there are many types of errors. Programmers can check the type of an error to determine what went wrong and react accordingly. Errors can be thought of as objects and their types as classes that can be subclassed like any other class. But unlike other data, they follow an error-specific path through the code, short-circuitiing functions all the way up the stack until handled.

Probably once a year, I end up back in the same discussion about timezones. I don’t like timezones and apparently I bring that up a lot. The Usual Griping Programmers’ hatred for timezones is a bit of a meme. (I just googled “xkcd timezones” with absolute confidence there would be a comic, and of course I was right.) Computer systems don’t play nice with different times across the world. If I run a retail website, “weekend” sales should begin Saturday morning and end Sunday evening your time, even if it happens to mean that’s not the weekend where I am.