Re: Try/Catch
- Posted by Spock Feb 10, 2015
- 4645 views
If the program accesses the error/status code inside the called routine the compiler will insist that the caller check this outside after each call. Or at least issue a warning so that the programmer knows about it. That would solve the issue of knowing where to check for errors.
That's fine if a routine can return a status. A procedure can't, and neither can indexing.
Wrong. Any type of call or operation could "return" a status code - via PBR
Issuing a warning is really only useful if a programmer is the one using the program.
The warning is really useful to the programmer to track down logic errors and useful for the user since they then have the option to gracefully shutdown the system. The warnings could be suppressed for production code. Although, I think a log file could be created as well.
So you catch a bad index. Now what?
By definition, the code traverses up the call stack until it finds a catch clause to handle it.
So, to recover, you must explicitly write code to handle that case - there is no way around it. try/catch doesn't improve our programming. Doesn't make the code more concise, readable, understandable, stronger. I argue that having the recovery code right by the caller is better than having it anywhere else. A point which you have not (yet) denied.
Therefore, my argument remains: Where is the clear advantage of try/catch over smart status code?
Spock
