Error Handling

I sometimes say "the most important part of programming is error handling".

This is not true. Shown by how many programs, how many library routines, how much code, does not handle errors at all.  Successful programs, libraries, code.

How about "one of the hardest parts of programming is error handling"?  That error handling is hard is one of reasons it is so often neglected.

And "one of the biggest barriers to reuse is error handling".

In at least two senses:

(1) You pick up a tool or library, try to use it on what you believe to be correct input - and it craps out with something like a Python stack dump.  Rather than debug, you try something else. Whereas, if an error message had explained what the problem was - if the code had checked format, rather than assuming - then you might have fixed the input.

(2) In a much narrower sense, the error handling conventions a code assumes may get in the way.  E.g. I assume that you throw an exception, you assume that it returns 0. Or -1.  If throwing an exception, what type of exception object do I throw?  (I have given up, and just throw strings.)


Can you tell I am debugging Python today?  I'm not 100% sure, but the Python code I have encountered has made more such assumptions...

assert/ignore pattern

Here's a pattern I observed today. I have seen it before. (In my wont to record neat little tidbits that m,ay be worthy of further thought.) Started with code:

    Object* objptr = ...;
    assert( objptr->consistency_check() );
    assert( objptr->fooptr->consistency_check() );
    assert( more_consistency_checks(objptr) );
    ... do something with objptr ...

Now, often enough it might be correct not to error exit with an assert. Often enough, in my problem domain, if one of the consistency checks fails you can just ignore the object, and go on. In my domain, computer architecture, this may arise because of speculative execution. So, pseudo-equivalent code might look like

    Object* objptr = ...;
    
    if( ! objptr->consistency_check() ) {
    }
    else if( ! objptr->fooptr->consistency_check() ) {
    }
    else if( ! more_consistency_checks(objptr) ) {
        ... do something with objptr ...
    }

I know, you might prefer

    Object* objptr = ...;
    
    if( objptr->consistency_check()
        && objptr->fooptr->consistency_check() 
        && more_consistency_checks(objptr) ) ) 
    {
        ... do something with objptr ...
    }

but I have found that I often want to do stuff like keep stats for which forms of inconsistencies were found, i.e. which assert would have failed if we had been failing. Or

    Object* objptr = ...;
    try {
      assert( objptr->consistency_check() );
      assert( objptr->fooptr->consistency_check() );
      assert( more_consistency_checks(objptr) );
      ... do something with objptr ...
    } catch(...) {
      ...
    }

although it can be unfortunate if the catch is a long way away from the assert. You might want to specify the assert fail action at the assert - which is what the OF statements do. --- No biggy, just a pattern I have seen before.

Thinking about "Slowness at Startup"

I am recording these episodes of "Slowness at Startup" mainly to record hard data as to how real this problem is.

Partly because one day I was talking with Linus - at the approximately once a year dinner David Kanter arranges for Portland area folk - and I said, in passng "I hate opening my laptop, it always takes 5 minutes to come out of standby". Linus looked at me witheringly, partly with the "You stupid fool, you shouldn't be running Windows" attitude he always wears, but also disbelievingly because he said that "even Windows" came back from standby quicker than this.

Partly because I work with people who claim that they are responsible for Windows coming out of standby in 30 seconds or less, 15 seconds, etc. - and who say that they are going to get it to just a few seconds.

There is a major mismatch between what these guys claim, and what I experience.


I suspect that a lot of the mismatch lies in how you measure time to "Get out of standby".

I think that many of them measure it as "time to see the screen redrawn". Whereas I measure it as "time to actually being able to use my computer to get work done." For example "time for me to read the first email in my Outlook Inbox", which is fairly unambiguous, although it does depend on Outlook's state when I went into standby.

"Time to read Outlook email" is my main metric, although I have others, such as "Time to being able to use a web browser to do a Google search". Or "Time to my screen being resized to take advantage of the two monitors I have when docked, or to fot onto my laptop screen when undocked". (This can be critical, because it is pretty close to impossible to work when you have a large screen displayed on a small monitor, but, unfortunately, often the applications come up quickly but the screen resizing (Thinkpad Presentation Director) takes a lot longer. Not to mention that resizing my screen often takes 2-3 minutes in and of itself.

It has been a truism that one should design systems to get the screen drawn quickly, even though the application is not yet ready to do so. I am not so sure that this is a good idea any more - I find it quite irritating that a window is up, doing nothing, while the application is ever so slowly coming back to life. I find it hard to tell the difference between an app that is coming back slowly, and one that is dead. I probably waste a lot of time killing such apps, and restarting.

I think that it might be better user interface design to make it explicit what is happening to app.

Instead of

(0) Window manager draws a frame, but the window contents is blank
(delay of a few minutes)
(1) Application receives a redraw event, redraws the window contents, but isn't ready to respond to keyclicks
(delay of a few minutes)
(2) Application is finally responsive

with no visual difference between (1) and (2), except maybe for the hourglass cursor, which isn't reliably displayed, how about:

(0) Window manager draws a frame.
Window manager redraws the window contents from backing store.
Window manager greys or shades the window, to indicate that the app is not ready yet
(1) OS doesn't even allow the application to do anything until its working set is loaded
(delay of a few minutes)
(2) Application working set (from before the standby) is loaded, app can be expected to be responsive.

This gets you to the place where you can see the window contents quickly, quicker than Windows does now. You can flip through apps, or, if you are like me and often have your calendar up, look at an old display of your calendar, which may have the info you need.

But it delays making the application appear to be ready to talk to you, until it truly is. Thus diminishing that frustrating "I don't know if the application is ready or not" delay that trakes 5 or more minutes on my current system.

For extra credit, ungrey buttons as the application is ready to deal with them. For example, ungrey the close window / kill application button as soon as possible, but only ungrey resize when thre application is ready.

---

I'm not going to say "It's not the slowness, it's the user interface that makes the slowness more frustrating". Because the slowness is a problem.

But the user interface is particularly annoying, and exacerbates the slowness.