Re: Try/Catch
- Posted by mattlewis (admin) Jan 08, 2015
- 5680 views
"What we need is a compelling argument for why recovery should be an option after a Throwable is thrown"
OR
"What we need is a compelling argument for why recovery should be an option after an unrecoverable occurs"
I think the answer to the former is self-evident. I don't think a compelling argument for the later exists, as the situation is by definition not recoverable. But the latter also has nothing to do with dcuny's original example and use case which lead him to ask about adding try/catch in the first place!
But what's the difference between a recoverable and unrecoverable? What about a bad subscript in a function? Calling routine_id -1? Again, anything that would normally call RTFatal could potentially be recoverable in one circumstance or another. This doesn't stop you from a fast fail development, either, assuming you watch / log these and fix them as you find them.
Note that none of this necessarily assumes try/catch vs what Go does (I remember looking at it a while ago, but I haven't gone back and refreshed my memory and I don't think it matters while we're arguing over the basic principles here).
Matt
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.
I agree in principle. Actually getting this right is very hard in practice, hence the popularity of try/catch as a crutch.
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.
Why is Throwable handling pointless here? If the Throwable wasn't caught, the IDE would have crashed and taken down all of Matt's unsaved work with it. I don't see this as the preferred outcome.
From the perspective of the IDE writer, it's easy to anticipate a badly written plugin (perhaps still in beta) crashing and throwing a Throwable. But this can be handled - catch the Throwable and maybe disable/unload the plugin. And pop up a message box so the bug can be reported from the user to the developer of the bad plugin.
[/quote]
