Seems like more and more I’m finding applications that have little or no error handling strategy, which is a real shame. The job the application is performing is important to me: I want to use it to save myself the time and headache of doing something repetitive or mind-numbing. Unfortunately, while the application does its job well, it fails on less than perfect input. Now, I’ve been using computers since I could barely say “computer,” so I’m well-versed in telling my computer what it wants to know, in the format that it wants to know it. And I’ve become accustomed to looking at tracebacks and using other tools (strace, ltrace, gdb, etc.) to find what is breaking, and correct my input. However, that doesn’t work for your average user–even if your average user is a developer. The end result: the application ends up with a bad rap pretty quickly. This is especially true if you have a command line application, and you have a bunch of users who aren’t command line junkies.
I’ve been spending a lot of time lately on the Python Wiki trying to figure out if there is material, advice, basically anything that could help me start a Python Users Group. I happened to be running through an area trying to collect articles/useful information in a format suitable for conferences and user groups, when I ran across an article about embedding python. It’s actually a very good article, despite being 8 years out of date. And, to be honest it’s exactly how you would embed Python today, except you may want to use
Py_InitializeEx() to keep Python from attaching signal handlers. I wish I knew of this article the first time I tried embedding Python. Might have saved me from reading a lot of source code.
So, one opinion I’ve upheld for a long time was the idea that you should feel the pain of your design decisions. Why? Simple: you learn about the consequences of those design decisions. On the surface, it may appear that you made some excellent trade-offs, while in reality it turned out to be less than ideal.