Re: Try/Catch
- Posted by DerekParnell (admin) Jan 07, 2015
- 5863 views
What's not to like?
Haha ... I'm sure someone will object. Human nature I guess.
Control does not return to the application.
The issue here would be, in dcuny's original example, that there is still no way to handle 'x = s[i]' effectively without having the program (eventually) crash. This is still an improvement (as least you have a last-ditch chance to save any unsaved data), but you can't deal with unexpected exceptions and pick off from where you left off. Maybe that's a good thing.
The thing here is that the example is not an exception, in my opinion. If the causes an error, then I'd regard it as a case of invalid data. In which case, 'data validation before usage' is a better approach.
I regard exceptions as those things that originate from outside the control of an application and that cannot be effectively anticipated by it. That's why the application should terminate, possibly after doing some damage control/mitigation first.
Data errors can be best dealt with by validating data coming into the application at the earliest practical point it enters the application.
Uninitialized or incorrectly initialized variables should be discovered during testing. One certainly should find those mistakes before your customers do. Unittests to the rescue!
- Make RTFatal() callable from user written code. This effectively implements the 'throw' concept.
We already have crash() for that. Or do you mean a resume_trapped_ex() which could only be called from inside the trap handler?
Ah... I forgot about crash(). That would do nicely - one less thing to implement. 
