OnBoard C

--- Steve Little <steve@...> wrote:
> Really there should be a better
> method for reporting
> errors, but it would potentially require a huge
> overhaul of teh codebase.

Without the overhaul, we have to keep stepping on the
bugs, one by one, as they come up. Without a
methodology on how to handle this type of situation we
have to rely on each developer to guard against this
situation in their own way without introducing new
bugs.

If we standardize a mechanism, it provides an example
for new developers on the project (like me) on how
things should be done.

> > Being indoctrinated of late in Java and Scheme, is
> > there a mechanism we can use for throwing
> exceptions
> > that can be caught at a lower level, effectively
> > giving us a way to jump out of a routine and
> unwind
> > the stack (like call-with-continuation in Scheme)
> in
> > C?
> 
> rotfl... Are you kidding? :)

Actually, no, I am not kidding.

> Seriously though, no,
> nothing nice like
> exceptions in C.

Not in C, but in the Palm API there is. I remembered
seeing ErrCatch, ErrThrow, and ErrTry, so I read up on
it last night. It is exactly what I was referring to
(from the Palm Companion):

"The error manager is aware of the machine state of
the Palm Powered™ handheld and can therefore correctly
save and restore this state. The built-in try and
catch of the compiler can’t be used because it’s
machine dependent.

Try and catch is basically a neater way of
implementing a goto if an error occurs. A typical way
of handling errors in the middle of a routine is to go
to the end of the routine as soon as an error occurs
and have some general-purpose cleanup code at the end
of every routine. Errors in nested routines are even
trickier because the result code from every subroutine
call must be checked before continuing.

When you set up a try/catch, you are providing the
compiler with a place to jump to when an error occurs.
You can go to that error handling routine at any time
by calling ErrThrow. When the compiler sees the
ErrThrow call, it performs a goto to your error
handling code. The greatest advantage to calling
ErrThrow, however, is for handling errors in nested
subroutine calls.

Even if ErrThrow is called from a nested subroutine,
execution immediately goes to the same error handling
code in the higherlevel call. The compiler and runtime
environment automatically strip off the stack frames
that were pushed onto the stack during the nesting
process and go to the error handling section of the
higher level call. You no longer have to check for
result codes after calling every subroutine; this
greatly simplifies your source code and reduces its
size."

> > Or should we simply start adding Err or Boolean as
> > return values to any functions which set values to
> > global variables upon which the calling routine
> > depends?
> 
> As mentioned above, typically the way this has been
> done in the rest of
> the code is to return a NULL value, and make sure
> that all levels check
> for null:
> 
> charPtr do_something(){
> 	if(something goes wrong)
> 		return NULL;
> 	else
> 		return somethign_else;
> 		//typically current position in the code, or a
> Node *, etc)
> }
> 
> Then calling functions are things like:
> 
> charPtr do_somethign2(){
> 	CharPtr result = do_somthing()
> 
> 	if(result){
> 		// do more stuff
> 	} else {
> 		return NULL;
> 	}
> }
> 
> So the NULL should propogate up, unwinding the
> stack. The only problems
> occur if the error is not reported at the bottom
> level, or if the NULL
> isn't checked for at all levels.

It is also a problem where a function calls another
function which sets the value of multiple global
variables. Then the calling function uses those
globals without explicitly checking first.

> It's not very pretty, but it works (most of the
> time)

Well, my attempt at compiling OBC with OBC revealed
that one exists, plus the problem listed on the boards
indicated another where this pattern was not followed.

I guess my point is that we should have items like
this in the developers docs -- patterns if you will --
that help indicate how certain types of situations
should be coded.

Personally, I am all for trying ErrTry/ErrCatch. It
would have been nice if they included ErrFinally, but
oh well. Also, this mechanism is listed in the API
docs for SDK 3.0, so it would support all of the Palms
that OBC currently supports (I believe).

> but I'd suspect that a fix like this would be the 
> quickest and easiest way to solve it. It'd also be 
> in keeping with the rest of the code.

I am sure it would be the quickest way too. I believe
I already pinpointed the exact line.

> That said, I'm not a big fan of the current system,
> I'm just wary that
> it'll take a huge rewrite to replace it....

If you get a chance, would you (and others) look over
the ErrTry/ErrCatch mechanism? I think you might find
that we could actually refit without too much effort.

I think we are setting up for an overhaul anyway, if
we are going to change from DB-based compiling to
line-based compiling. Also, adding VFS support will
likely add a good chunk of code which could certainly
benefit from applying a new pattern.

Dale

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

> Without the overhaul, we have to keep stepping on the
> bugs, one by one, as they come up. Without a
> methodology on how to handle this type of situation we
> have to rely on each developer to guard against this
> situation in their own way without introducing new
> bugs.

Well, technically, this bug would have been there independant of error
handling mechanism (either exceptions or old skool C returning error
status.)  The problem is really that there was none there at all in this
case. (ie, it's the equivalent of if exceptions had been used, but with
no catch()!)

So I think we'll still find unhandled errors one by one even with
exceptions. The good part about exceptions is that some top level
catch-all (pun intended) stuff can be done, so that even if no pop-up
message is given, it's spotted somewhere.

> If we standardize a mechanism, it provides an example
> for new developers on the project (like me) on how
> things should be done.

Very true. The error handling is IMHO one of the nastiest aspects of the
existing code.

> > rotfl... Are you kidding? :)
>
> Actually, no, I am not kidding.

Sorry, I was joking, I just like ridiculing C as a language for being so
very crude and basic. No offense was intended to you (just to C!)

> Not in C, but in the Palm API there is. I remembered
> seeing ErrCatch, ErrThrow, and ErrTry, so I read up on
> it last night. It is exactly what I was referring to
> (from the Palm Companion):

Cool! I'd not heard about that, I'll go read up about it ASAP. This would
be a really nice way to handle errors in OnBC...

*snip Palm Companion stuff*

I'm not 100% sure about them, so I'll hhave to read up. They sound a
little like a poor mans version of exceptions, and therefore not so nice,
but that might just be because of the way the article tried to explain
them...

> It is also a problem where a function calls another
> function which sets the value of multiple global
> variables. Then the calling function uses those
> globals without explicitly checking first.

Yup. Again, there's quite a few places where the error checking is lazy or
non existent.

> > It's not very pretty, but it works (most of the
> > time)
>
> Well, my attempt at compiling OBC with OBC revealed
> that one exists, plus the problem listed on the boards
> indicated another where this pattern was not followed.

Yup, I suspect there's several lurking...

> I guess my point is that we should have items like
> this in the developers docs -- patterns if you will --
> that help indicate how certain types of situations
> should be coded.

Agreed.

> Personally, I am all for trying ErrTry/ErrCatch. It
> would have been nice if they included ErrFinally, but
> oh well. Also, this mechanism is listed in the API
> docs for SDK 3.0, so it would support all of the Palms
> that OBC currently supports (I believe).

I like the sound of them, but I've not read up properly. As mentioned
above, they'd have a few really nice advantages. However, they won't solve
all our problems. There will still be places like the one mentioned on
Yahoo where unless the catch was put in, the next function call would fail
causing a Fatal alert.... This means we still need to find lots of little
places like that where errors are not being handled...

> I am sure it would be the quickest way too. I believe
> I already pinpointed the exact line.

Cool. I propose that we quickly fix this bug this way (for now). Would
anyone care to second this as a Quickfix?

Dale, could you add the bug and a description to the Bug Tracker on SF, so
that it gets recorded properly, and noted as fixed in the next relase,
please?

> If you get a chance, would you (and others) look over
> the ErrTry/ErrCatch mechanism? I think you might find
> that we could actually refit without too much effort.

You might be right there. I'll read up ASAP and get back to you with my
opinion. If they're designed like c++ or java exceptions though, it would
be trivial to build in at least the basic handling. ie, as a first stage,
add some top level try/catch statements, and a 'throw' in the error()
function (which currently pops up an alert). Then we can go through adding
more fine grained handling of exceptions.

> I think we are setting up for an overhaul anyway, if
> we are going to change from DB-based compiling to
> line-based compiling. Also, adding VFS support will
> likely add a good chunk of code which could certainly
> benefit from applying a new pattern.

As mentioned in a previous post, I think the line based compiling could be
quite simple to implement (but I've not really looked into it yet) since
the access to the file is well encapsulated.

Big overhauls are unavoidable, and often a good thing. Have you read the
document about branching and merging using CVS? this is an ideal way to
handle big changes which require the whole tree to be worked on for a long
period of time.

As it happens, it seems that exceptions might not require a very big
overhaul. I was thinking of a completely new error handling method, such
as each function returning an ErrType or Bool. Now that really would be a
big overhaul....

Thanks again for the info on exceptions!

--- Steve Little <steve@...> wrote:
> > Without the overhaul, we have to keep stepping on
> the
> > bugs, one by one, as they come up. Without a
> > methodology on how to handle this type of
> situation we
> > have to rely on each developer to guard against
> this
> > situation in their own way without introducing new
> > bugs.
> 
> Well, technically, this bug would have been there
> independant of error
> handling mechanism (either exceptions or old skool C
> returning error
> status.)

I was not clear. I meant that _going forward_ we will
remain in the same boat unless we develop and document
a preferred mechanism for handling these situations:
where one function calls another and the called
function does not properly signal the calling function
that a catastrophic error occurred.

> so that even if no pop-up
> message is given, it's spotted somewhere.

True. I zeroed in by grep'ing the dialog's message.

> They sound a little like a poor mans version of 
> exceptions, and therefore not so nice, but that 
> might just be because of the way the article tried 
> to explain them...

It makes it a bit uglier with no "ErrFinally". Cleanup
could be a problem.

> There will still be places like the one mentioned on
> Yahoo where unless the catch was put in, the next
> function call would fail
> causing a Fatal alert.... This means we still need
> to find lots of little
> places like that where errors are not being
> handled...

Nevertheless, it can handle the situation where:

funcA () {
  funcB ()
  ... do something based upon funcB's actions
}

funcB () {
  funcC ()
  ... do something based upon funcC's actions
}

funcC () {
  ... check for problem
    ... error detected in which we cannot go forward
    error("Some message")
    return
  ... continue with funcC's actions
}

Instead, we could do something like:

funcA () {
  ErrTry {
    funcB ()
    ... do something based upon funcB's actions
  }
  ErrCatch {
    ... error caught, so stop compiling and clean up
    error (messageCaught)
  }
}

funcB () {
  ErrTry {
    funcC ()
    ... do something based upon funcC's actions
  }
  ErrCatch {
    ... error caught, so clean up
    ErrThrow (messageCaught)
  }
}

funcC () {
  ... check for problem
    ... error detected in which we cannot go forward
    ErrThrow ("Some message")
  ... continue with funcC's actions
}

> Would anyone care to second this as a Quickfix?

I will second.

> Dale, could you add the bug and a description to the
> Bug Tracker on SF, so that it gets recorded 
> properly, and noted as fixed in the next relase,
> please?

It is RequestID 877710.

> Have you read the document about branching and 
> merging using CVS?

I have been remiss in my education of CVS. :(

Dale

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Done!
--
Wade Guthrie
wade@...