From: Walden H. Leverich
How does the joblog help you debug a
missing customer? Not the entire table, just a missing row... You know,
debugging those inevitable "the row must be here... but it's not..."
errors? Or help you deal with errors in logic in computing the price of
an item? Or it's shipping weight, etc.?
First, these ARE system level errors. You have some bad data if you're
missing customers, and if you are using a log to debug logic errors, you
don't deserve to be coding.
But beyond that, this is where the feature I mentioned in my previous email,
the ability to go in and start a debug session on a running job, is so
powerful. If I program in simple assert logic to check for unexpected fatal
data conditions and I throw an error message to the system operator, the
programmer can go in and debug the program. This will work for interactive,
batch or even web applications. And with WDSC, I can even set a service
entry point on the assertion program and gain control directly into WDSC
automatically.
In fact, the only thing that you can't (or perhaps shouldn't is the better
term) handle this way is the infamous intermittent error, which probably
needs old-fashioned logging.
The joblog is great for system-level stuff. There's no argument there.
But I'd guess most "bugs" aren't system-level issues.
Ah, that's Windows programming vs. midrange programming. The way I learned
to program, you actually tested your code before it got into production,
including end points. You know, all that old rigamarole about having test
plans and unit tests and integration tests, which is now pooh-poohed by the
extreme programming crowd <chuckle>.
That stuff made sure that the programmer found all but the most severe
data-derived errors in programming, and then put hard halts in place for
even the data errors. Yes, occasionally bad data gets in (especially when
you allow ODBC updates to your data) but even then your program should
either alert the system operator, or in those cases where you must continue
processing, then indeed it needs to log the problem.
If, on the other hand, you regularly have bugs getting into production, then
you have a serious problem in your development environment. And the idea
that bugs in production code are to be expected, and even tolerated, is
perhaps the single most destructive thing Microsoft has done to the IT
industry.
Not that I have an opinion on the issue or anything <grin>.
Joe
As an Amazon Associate we earn from qualifying purchases.