D
dbeavon
Guest
I could only get to this point before I stopped reading: >> Our intrepid short-attention-span test-driven-developer is three levels deep in void functions and suddenly discovers a potential error condition. He doesn’t want to “refactor” three void functions to return error codes, he has a foosball game with the team in five minutes, so he issues a call to throw and wraps the call to the first of the void functions in a try-catch block and runs off to his game. Facepalm. The author clearly misunderstands SEH. The main purpose of an exception is to carry an error-related output from a method back to its callers (client programs). This output is used when *all* the other behavior of the method has been rendered irrelevant . In other words the exception is already an *implied* output parameter (and more besides - see PS***). So the author seems to be asking us to re-invent the wheel by putting errors in the returned results of all our methods, even though errors can already be sent back for "free". Besides, the return value of a function is typically already in use for some other purpose that is much more *relevant* from a semantic standpoint. I can just imagine trying to read the author's programs. They probably look a lot like the WIN32 API did when it was built decades ago... every method returns some obscure 32-bit error number ( System Error Codes (0-499) (WinError.h) - Win32 apps ) and nobody knows what the error number means until they look it up on some bureaucratic reference chart. Also, every client of every method has to check the error result before proceeding to ensure that it returned a zero or whatever. Thank goodness for S.E.H. and for the fact that there are more people who understand its benefits than the ones that don't. Note that appserver in OE 12 is being enhanced to marshall errors/exceptions all the way back to an openclient. Thankfully Progress understands S.E.H. pretty well (with certain exceptions like the lock-wait timeouts that were designed to fall out of my last-ditch exception handling). *** PS. SEH is also a control-flow tool. The language will give you catch/finally structures and will take you back down the callstack as far as needed.
Continue reading...
Continue reading...