Re: Try/Catch
- Posted by jimcbrown (admin) Feb 13, 2015
- 4188 views
In 99.99 % (or thereabouts) of cases the programmer will NOT know what that correct runtime value is. Insisting otherwise is completely absurd!
You're not going to try to provide a value for a bad index..
Right. Neither Exceptions nor SCC can do this any better than the other.
dcuny and I part ways here. I think, if the programmer knows what they are doing, providing a value for a bad index works.
So the comments implying that Exceptions could solve a bad index better than SCC were muddying the waters just a bit, eh?
Not at all. There's another problem with SSC that I eluded to earlier.
This is what was written:
Don't forget what I wrote:
But that just asks the question of why the programmer didn't correct the logic error that led to the exception being raised in the first place!
Probably for the same reasons that some callers of open() check the return value to see if it's -1, instead of trying to prove that the file exists and permission to read it is granted before calling open() and then gets().
"they all share the same problem" - not stated what this is
The problem is that whatever value that ends up in the variable, it's not obvious that the variable has now been set to this. It's also not necessarily obvious that this happened at all (that the variable got a "default" value instead of having the operation be successful and getting a real value back).
"whereas, try/catch doesn't" - not stated how this is any better
This doesn't have the issue because one generally sets the variable explicitly in this case. Also, the flow of execution is deliberately interrupted here, which makes it clearer that something went wrong.
Because you were referring to things like "[bad indexes are] the typical exception in Euphoria." this is why I was focusing on that low level aspect. For the high level this can still be done with SCC. Only that the traversal path must be manually coded. Still, no tricky stack unwinding is needed. Just return the functions via an error path. Granted. More verbose (what Jim calls 'ugly') but, I think, very robust.
The extra verbosity is strongly akin to having "the programmer ... corret the logic error that led to the exception being raised in the first place!"
That is, if you can do all the if statements necessary to catch the would-be Throwables in SSC, you could just rewrite the code to not have the same logic errors in the first place... whereas "try/catch allows you to keep running on three wheels when a tire has blown out" as noted by dcuny.
