[Tutor] try..except - what about that ton of **Error statements?

[boB Stepp]

On Wed, May 22, 2013 at 8:47 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On 23/05/13 02:09, boB Stepp wrote:
>
>> I would like to ask some general questions here. Problems can arise
>> from bugs in the operating system, bugs in the programming language(s)
>> being used, bugs in packages/modules being used, bugs in any third
>> party packages being used, etc. Also, whenever any one of these things
>> is updated/upgraded, it can introduce new issues. What strategies can
>> one use to deal with these possibilities that seem entirely out of the
>> programmer's control?
>
>
>
> They're not really out of your control though. You can always write code
> to work around them.
>

I have found myself having to do this when I write scripts for my
radiation planning software at work. There are frequently rather
quirky behaviors in this software that I have to work around. And
there seems to be a different set of quirky behaviors every time the
software is upgraded.

[...]

>
> Sometimes it is sufficient to just avoid triggering the bug. Sometimes you
> might need use a different tool. For instance, in Python, print is not
> "thread safe" -- if you have two different threads trying to print at the
> same time, their output may interleave.
>

I did not know this.

[...]

>
> So working around bugs is, in general, possible, even if sometimes it is
> hard.
>
> A general technique when programming is to always have a good, solid test
> suite. This will detect any change in behaviour, whether due to your own
> programming errors, on bugs in the language or operating system. What you do
> is as you develop your own code, in parallel you also develop a second
> program that tests as much of your code as you can.
>

I guess this is the test driven development I have heard about.

[...]

>
> (Or you can use a test frame work like unittest or doctest or both.) Now,
> whenever you change something, say you upgrade to a new version of the
> language, or change your code, you run the test file and see what tests
> start failing. Each failed test indicates a bug that needs to be fixed,
> although it doesn't tell you what introduced the bug.
>
So this method of development is a good friend that keeps on giving! ~(:>))

More general questions: How do you keep up with the ongoing changes in
your development languages? One thing I have found frustrating in
learning Python at my rather slow pace (Due to limited time.) is that
the versions keep changing! Worse, at least in the case of Windows, is
there is a constant deluge of security updates, etc. Are you
constantly reading release notes to keep up? Is there a more efficient
way? It seems that if one has written a significant program for
Windows one would have to run one's automated test suite every time
there are updates. I wonder how often problems arise that have to be
dealt with? At least with Solaris at work, they only update the OS
when they update the hardware.

This has been very informative! I have so much to learn...

Thanks!
boB