Status-subtype / Re: SDL 1.3 proposed conventions

What do people think? Good? Bad? Ugly?

To add a thing that had not been asked: the posix-style
errno/status-codes are no good - I see people usually
fail to check for EAGAIN EDEADLK EINTR type statuscodes
and handle them appropriatly. Just encode a severity-
or howtohandle-mark into the statuscode, usually four
levels in the lower two bits of the status-int are
all that is needed, syslog knows eight, more is insane.

Basic classific of status-codes is even more needed
with extra modules that the original application may
eventually have not been designed for… and for
which the app does not correctly expect and handle
the status-codes. And not every status-messages
means an error that should end in an exit()-call,
many things can be retried and reinited. A status
message just means to go not along the standard
path of execution.

Perhaps I should have added that I have an academic
background in failsafe distributed computing and that
I do work now in telecommunications where you just
don’t exit(). And whereever you have style of
concurrent execution and where your communication
lines between the threads get a state - there is a
great need to have some inner-application diagnostics
that is a bit in between exit() and loggingandignore().
Actually, the three mentioned status-codes like
EGAGAIN EDEADLK EINTR have a background in
concurrent execution, actually all unix-programs
should expect such errors but they often don’t
do, and a multithreaded SDL-using project should
expect and handle many of such errors just as well.

Original SDL may have just been grabbing the local
video/sound resources on an exclusive basis, so many of
the tricks in concurrent access don’t exist but the
things are a bit different e.g. for extension-libs
based on sdl_net or just device-access via nfs. There
are many extension-libs for sdl now, and an sdl-based
app may be quite huge these days I think, and even that
the C++ way of excpetionism is brutal (if working at
all) we have two observations - many things that are
errors to lowerlayer-parts can be handled by higher
layers of the application if not just reinit()ing
with slightly more conservative options instead of
exit()ing if it had not gotten what it wanted in the
first place, and secondly rolling too much information
is overdone in this task - the higher layers will
usually work by category, and not by the specific
details - the specific errors should have been
(partly) managed on lower layers anyway.

cheers, Guido

Rainer Deyke wrote:

“Guido Draheim” <Guido.RR at gmx.de> wrote in message
news:3B1083AC.E80D02B4 at gmx.de

What do people think? Good? Bad? Ugly?

To add a thing that had not been asked: the posix-style
errno/status-codes are no good - I see people usually
fail to check for EAGAIN EDEADLK EINTR type statuscodes
and handle them appropriatly. Just encode a severity-
or howtohandle-mark into the statuscode, usually four
levels in the lower two bits of the status-int are
all that is needed, syslog knows eight, more is insane.

Don’t blame the API for the mistakes of the users.

Error codes (i.e. non-success status codes) can be divided into categories:

  • “Try again” errors. If the best response is to call the function again,
    why return at all? These error codes are best eliminated entirely.
  • Programming errors on the user side. This usually means bad arguments
    for a function. The only appropriate response is to inform the user and
    terminate the program.
  • Fatal errors. Think “heap corruption”. Again, the only appropriate
    response is to inform the user and terminate.
  • Serious environment errors. Think “out of memory”. There are several
    three possible responses. You can fix the problem. You can avoid the
    problem by using an alternate strategy. Or you can terminate the
    program.
  • Non-serious environment errors. These can be safely ignored. Think
    "failure to play sound". Of course, if the program only communicates
    through sound, this becomes a serious error. There is no general way
    for SDL to tell if the error is serious or not.

Conclusion: the only generally appropriate response to an error is to spit
out an error message and terminate the program. All other responses must be
individually coded for a specific error. That is not that say that a
classification system wouldn’t be useful. At least it makes it easier to
differentiate between real bugs and running out of memory.


Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor

– guido Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- h.r(*@)>+++ y++ 5++X-

Hi,

I know I’m new but I’d like to add just a very small note… shy smile

  • “Try again” errors. If the best response is to call the function again,
    why return at all? These error codes are best eliminated entirely.

I think that’s not always true. Keeping retrying infinitely can lead
to a deadlock in some cases. Imagine a read() on a packet oriented
socket…

Have a nice day,

Jiri “BlueBear” Dluhos–

It is really quite easy to imagine a square yard of multidimensional
space, provided that you have seven brains.

                                      Prof. Abdullah Nightingale
                (Walter Moers: 13 1/2 lives of Captain Bluebear)

Jiri “BlueBear” Dluhos
Software Developer, HUMUSOFT s.r.o. (http://www.humusoft.com)
dluhos at humusoft dot com (office)
dluhosj at centrum dot cz (home)

Jiri Dluhos wrote:

Hi,

I know I’m new but I’d like to add just a very small note… shy smile

  • “Try again” errors. If the best response is to call the function again,
    why return at all? These error codes are best eliminated entirely.

I think that’s not always true. Keeping retrying infinitely can lead
to a deadlock in some cases. Imagine a read() on a packet oriented
socket…

That’s absolutly true - it should not be “ignored” - it should be
handled differently, possibly triggering a maxcounter or timer.
And yes - a helper function can memorize the “try again” error, do
some other task and return the error as its status-code, inside
a while-loop you’ll have to analyse it more deeply to prevent a
livelock situation. And indeed, I’ve seen code to simply ignore
the warning always, or to retry always disrespecting the need to
check a termination-condition for all loops out there. It seems
the programming-lectures just tell the students how to make
a loop but it’s not pointed out enough to put extra brain to the
question if it will indeed always terminate at some point.

@all, just an example I had yesterday - invent a status-code for
"user did hit the pc with the knee, cdrom did spin down and does
now spin up and recalibrate, just wait a second and it’s going
to be fine as before". Yep, that’s hard to express - let the
app break? let the app show a message-box? let the app put a
log-message and retry in a second? just ignore it?

cheers, guido