[aklug] Re: terminal types and curses programming

On Sat, 24 Jan 2009, Shane R. Spencer wrote:

> It's great to have good error handling, but experienced users know that
> when you're missing a TERM variable lots of stuff fails to work. And
> the generic curses error message seems to work fine. It's a shame when
> libraries like libncurses assume responsibility for exiting a program on
> behalf of the main function otherwise you could easily do error handling
> based on the result code of the function causing the issue. Grr, right?

I agree with you in principal, but there is some logic to it. The primary
basis being that they want to ensure that you don't do any destructive
processes to the terminal that might leave it in an unusable state. That's
considered the greater evil here. You have to remember that this is a C
API, too, so all kinds of mischief could ensue from allowing a program to
continue to make calls with uninitialized pointers, etc.

In a final defense of Curses (did I just turn into a fanboy?!) there's this:
the Curses API gives you calls to determine the supportability of the
terminal (remember setupterm(3)?) before calling the less tolerant
initscr(3). In fact, setupterm is called by initscr (among other functions),
so you do have the opportunity to trap these exceptions yourself. I agree
it is unfortunate that this eventuality isn't better documented, but I'd be
surprised if it isn't covered by any of the printed books on the subject.

> Python has some wonderful error handling for most of it's modules and
> extended modules and makes it very easy to attempt something that might
> fail and recover gracefully if possible. I've found that when I start a
> new program I want it to be something anybody in the world can use, but
> then I remember that I'm creating something not just any user in the
> world would even use. I usually realize this after I've just spent days
> creating fault tolerant code that has pretty error messages. Maybe this
> isn't the case for you, but I find that error handling often distracts
> me from getting the functionality working.

:-) It's all there and documented, just not as well cross referenced as it
should be, or as things sound like they are in Python.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Jan 24 13:11:34 2009