Re: Try/Catch
- Posted by dcuny Feb 10, 2015
- 4621 views
How does your try/catch idea correctly know how to recover from a bad index? In 99.99% of cases it won't - unless you place it at the caller point. So why not just have an explicit test there anyway?
It's not like I'm inventing a new concept here. It's been a standard feature in quite a few programming languages for some time now.
The short answer is: it doesn't know how to recover from a bad index. It know how to recover from a section of code that's been placed in a try block.
Try/catch won't somehow magically give you program correctness.
That's correct. It allows a program a structured way of dealing with exceptions.
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.
Issuing a warning is really only useful if a programmer is the one using the program.
I think the problem of a bad index is a very poor example to solve using try/catch.
Why is it a poor example? It's the typical exception in Euphoria.
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.
Have you looked into how try/catch works before arguing against it?
- David
