> 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
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
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
> > 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
> 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
> > 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.
> 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,
> 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
Thanks again for the info on exceptions!