Re: Try/Catch
- Posted by jimcbrown (admin) Jan 08, 2015
- 5814 views
Imagine I've got a program that generates a .wav file as output. I find that someone's written a library that generates .wav files from a sequence.
Hurrah! Only there's the possibility that perhaps the developer didn't do adequate range checking. If we use your definition of exceptions, I've got a couple options:
- I can read through the library, making sure that it traps all possible errors, or
- I can write my own library, just in case, or
- I can choose not to use Euphoria
While in theory I can anticipate range errors, this is tricky in practice.
I'd rather be using a language that allows me to gracefully recover from exceptions, than one that crashes.
As pointed out, if you chose not to use that feature... you still get an immediate failure.
Ok, so don't use Euphoria.
Why the heck did we add goto then? Adding a new feature like try-catch isn't forcing new users to use it.
Refusing to add it, however, is the same as forcing new users - who may have perfectly valid reasons to want it - to not use it.
In situations where I've had to gracefully recover from an Euphoria app, I've writen a nanny program and have it watch the other app. If the other app crashes, the nanny program restarts it so it can pick up where it left off.
However, there comes a point at which one must simply trust the code written by others.
Agreed. I've seen issues in the past where java.exe itself crashed, blowing the entire app in smoke. At a certain point, there's not a whole lot you can do about it...
On the flip side, why make it worse by forcing us to trust people when we don't necessarily have to? Keeping the number of people who have trusted access to your passwords is a good security practice. Adding try/catch so we don't have to trust the author of a random library as much to prevent our app from crashing in a production environment likewise seems like a good idea.
My argument goes something like this ...
The Euphoria run-time component has many potential calls to RTFatal() and the vast majority would be triggered by bad data or bad coding. Things that appropriate testing should be discovering. They occur when the application is demonstrably doing the wrong thing and the code needs to be corrected. Failing the application is not a bad course of action with these.
I think this is unacceptable if it happens in a production environment. The more code there is, the harder it is to test everything.
That doesn't mean you don't try, of course, but remember the adage: all software has bugs. Not "all software that hasn't been thoroughly and appropriately unit tested has bugs" but "all software has bugs".
On the flip side, this means software using try/catch also has bugs and can still crash. try/catch is not a panacea - but I don't see anyone trying to argue that it is.
Your application was trying to do something useful. Something unanticipated and outside of your program's control caused things to stuff up. So what is you program going to do so it can succeed in doing that useful thing? Now I'm not talking about logic errors in your code, or invalid data being presented to your program, or error codes that can be returned by functions you call. I'm talking about exceptions - rare events that for the most part you can safely avoid writing special code to handle.
This I agree with.
Ok, so I went a bit crazy with these examples. They are all theoretically possible and it could seem that exception handling isn't helping much.
By your definition above, I'd argue that these aren't really exceptions - errors, sure, but they're reasonably anticipatible and should be detectable and correctable with an appropriate amount of testing.
What we need is a compelling argument for why recovery should be an option after an exception occurs - and what exactly do we mean by recovery?
Are you talking about after a true exception occurs, or a not-exception like your examples? The difference is important.
