Re: Try/Catch
- Posted by DerekParnell (admin) Jan 08, 2015
- 5717 views
But let's say it failed and your code actually got control at the point of failure ... what sensible thing can your program do to carry on?
Sometimes crashing is the right thing to do. But if a feature of a big program breaks for some reason (let's assume user input that you didn't anticipate, because that's super common) that doesn't mean the whole thing should die. It might be possible to carry on with other aspects.
User input errors are not exceptions, in my way of thinking. User input ought to be validated a soon as practicable upon entering the application.
Here's a real life example I run into every day. In my day job, I work with a java project that uses JSF / xhtml markup for building web pages. I use Eclipse. Many of my files include other files. I can select an include statement, hit F3 and have the included file opened in the editor. For some reason, every time I do this, I get a dialog pop up and tell me that there was a NullPointerException. But I can click OK and get on with my job.
It's a bit annoying, and obviously someone has done something wrong here. I've never dug too deeply, but I assume it was the extension / plugin writer who wrote the xhtml stuff. I guess I could find another tool to use or try upgrading or whatever. Or at least report the bug. But...meh...I have better things to do (like get my work done) and at least I can keep working, and whatever that error was, it wasn't critical and was definitely recoverable, though it's a class of error that euphoria would crash upon.
Wow! Not only annoying, but an example of where exception handling is pointless. So someone went to the trouble of catching an exception that has no effect on the job you're doing with the application. Clever.
