Arg. Rant Time!

<rant>

I apparently needed to spend more time with the old team than I thought, as really simple stuff was missed, or not implemented correctly. What do I mean? Well guys and gals.. the mxp interface I wrote has assert() routines for a reason. You guys used a whomping 5 calls to it. I have over 10 in a single plugin I just wrote. Guess what... debugging and testing is MUCH easier in that plugin than any of the others. And guess what... you really SHOULD catch all return codes from all functions and equate them... even if its just to mxp.log or _log the event. (You really should recover from it... but alas... I get sloppy there myself) Limos is going nuts finding tonnes of backend bugs where because you are /dev/null'ing the returns and not verifying the return codes, you are missing lots of failures and errors. I have been impressed with all the validity checks and pretty outputs he has added (of my god.. he uses colors like a paint brush on a canvas *shutter*) and it really helps to figure out whats going on. I guess the hustle to get things done had everyone taking some short cuts that really should have been caught by me.

Its my fault... not yours... I should have helped mentor you into using the mxp interfaces and use of proper error checking more clearly. I want to apologize for that. I will do better next time to teach you.. and not promote such bad coding style by not showing your the right way, and worse yet...
doing it the wrong way myself in sample/prototype code. Oh and Paul, if you are reading this.... mind putting this in the cirriculum a bit more? They really should know this already when leaving the university. I know very few unix commands that don't have clean return codes. Nor API calls in both C and Java. Programmers should capitalize on that.


</rant>