Re: Try/Catch
- Posted by dcuny Jan 01, 2015
- 6379 views
Euphoria has recoverable errors, you just have to check for them. "Get()" and "value()" are the best examples of that. Checking if a file exists is another.
No, these aren't errors.
But for the sake of clarity: Euphoria doesn't have recoverable exceptions.
Again, this is typical:
s1[i][j] = s2[k][i]
It happens often in Euphoria, and there's no nice way to recover from it.
Unrecoverable errors are ones where your program is wrong and is in an undefined state, so crashing is the correct behavior.
The idea that a program should crash is baffling to me. While it may be a theoretically correct behavior, it's not a desired behavior.
Consider the following use case: A user has created a file using a text editor that can save in formats X, Y and Z. The user has been working on multiple documents for the last half an hour, and are getting ready to save them. Unfortunately, there's a trivial bug in the editor, where the length of the filename is miscalculated as 1 character too long.
The user tries to save a file they've been editing in format X.
Which of the following behaviors would the user desire:
- The program should crash and the user's data should be lost, protecting the user from potentially corrupted data.
- The program should crash, but save the files as TMPnnn.zzz which the program will find when it loads again.
- The program should inform the user that there's a problem saving in format X, but continues to run and allows them to save it in format Y or X.
I can guarantee you option 1 is not the "correct" behavior, either as a user, or a developer.
The second option - save data - is more desirable. But as a user and a developer, I can assure you that I don't want my program to crash on errors. I want it to recover as gracefully as possible. As currently designed, Euphoria doesn't do this, and that's not good.
Arguing Euphoria is saving me from data in an "unknown" state, but that's not entirely accurate. Euphoria has enough information to inform me of what the state of the data is (I can determine the type of error, and where it happened). I should be able to take advantage of this information to decide what the proper course of action, not have some "one size fits all" crash behavior.
As currently written, Euphoria doesn't have an exception recovery mechanism. It has a callback that can be executed on an exception, but it can't recover from that exception.
Edit: The nice thing about "defer" in Go code is that it puts the release of the resource close to the allocation of the resource, instead of at the bottom of a section of code.
Yes, it's very cool. However, it doesn't map well to Euphoria's IL code model.
- David
