Re: Try/Catch
- Posted by DerekParnell (admin) Jan 08, 2015
- 5787 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.
However, there comes a point at which one must simply trust the code written by others. You do it already ... how do we know what machine code the C compiler actually generates ... perhaps it could generated incorrect stuff? So with this hypothetical library, it is not designed to fail so if it does, either get it fixed or stop using it. 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? Basically it boils down to --- don't call the library routine with that same data. You call it with different data but what data? And why would different data not also potentially cause a failure again? Your trust in this failing library must now extended to any call you make to it, thus effectively invalidating the use of the library for anything.
