Re: Try/Catch
- Posted by dcuny Jan 01, 2015
- 6501 views
Raymond Chen is always worth a read:
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx
I don't see Raymond offer a viable alternative to try/catch, only an argument that it's not perfect.
How is this helpful? 
I would think that you need some kind of stack unwind.
I think you misunderstand. I meant to state the very obvious - RTFatal currently stops code execution, and that behavior would have to be altered in order to handle exceptions.
I'd suggested that opcodes be put in place to check the return status from a routine that might set a fatal condition.
You can't simply perform a call stack unwind because traditional try/catch blocks can potentially be nested.
Plus, you need to handle the exception at the local level, where the exception took place. How is unwinding to a prior call helpful, if a local resource needs to taken care of? The prior call can't see into the routine with an exception.
All excellent arguments for not adding finally (an awful, stupid, confusing concept) to Euphoria.
Please explain your issue with finally.
For handling system resources, it's essential that they be released correctly. finally guarantees that this will have the opportunity to happen.
How is this bad thing?
If the main point of exception handling is to separate error handling code from the main logic, what is wrong with putting such things in a separate routine?
The point of structured exception handling is to handle exceptions in a structured manner.
One huge problem with calling cleanup() is that it hasn't got access to the local variables. How do you close a resource in cleanup() when you don't have the handle to it? How do you save the user's current work when #cleanup() can't see the data structure the user was working on?
How can you handle the exception at a level the exception didn't happen on?
It makes me madder than hell to think of such a horrible backward construct being added to Eu, if two simple calls would do.
That's a big "if".
Often, to simple calls won't do. How you you pass the context of the current call to your cleanup() routine? Having try/catch scoped to a block inside the offending call solves that problem.
Of course if you are not re-throwing an exception, which I would have thought is more likely anyway, or are prepared to use a simple flag/return value, <such code> can and should just go after the end try.
I'm not sure I follow you here. Whether you re-throw an exception depends entirely on what the exception was, and how it should be handled.
...though (as I said) a stack unwind based approach might be better/easier.
That's assuming that stack unwinding is appropriate. I've already noted why this may not be appropriate:
- The context of the exception is lost, so it can't be handled.
- Structured exception handling can be structure, so unwinding the call stack wouldn't work
Of course the other burning question is why someone might want exception handling
Because exceptions need to be handled.
Halting isn't a robust way of handling exceptions.
- to write good quality robust code, but without the messiness of error code handling
You've lost me here. try/catch is error handling. Euphoria currently hasn't got solid error handling. If something slips past your tests, the current error handler hasn't got access to the context, and can't recover or have access to the local data.
If you're going to suggest that any data that needs to be recovered should have been stored in global variables, that's basically ignoring the point of structured programming.
- to use badly written unstable garbage, and get away with it.
Why you assume this to be the case?
Personally, I genuinely prefer the messiness of error code handling, as it is easier to follow and easier to debug, and of course I worry that (most) people will think they are getting something which is actually really hard to do right, for free.
What "error code handling" are you referring to? Prior to adding crash_routine to Euphoria, there was no error handling in Euphoria - it simply crashed by design.
The current crash_routine isn't error handling, because the error isn't actually handled - Euphoria then goes on to halt. And Robert fought against even adding that much.
The reality is that no one can write fool proof code. But without some sort of way to handle exceptions, Euphoria users can't write robust code, because Euphoria isn't designed to be robust, it's designed to be fragile and not handle exceptions.
