2 ms·
The I/O example and comparison to Java is curious: > In this case there are two comparisons needed, one for end of file (EOF) and another for all other errors.
by peeters 11y ago
The I/O example and comparison to Java is curious:
> In this case there are two comparisons needed, one for end of file (EOF) and another for all other errors. Since Java does not allow errors to be compared as logic elements, as under Icon, the lengthy try/catch syntax must be used instead.
Can you really say it's a desirable feature for a language to treat EOF and other errors, like file not found, in the same way?
- TuringTest 11y agoFor an End-User Development language, it certainly would be. Errors could be handled like Excel does, by trying to execute as much as possible of the program and highlighting at runtime the cause of the error near the point where it is produced.
- pekk 11y agoThe passage is just clarifying the concept of goal-directed execution by comparison with the mainstream approach represented by Java, using a very standard example. There's nothing curious here, and there's no expository reason to start imposing additional requirements out of a suspicion that Java is being treated unfairly. Everyone knows Java is relatively verbose. Icon isn't forcing the distinction of EOF from errors, but that doesn't mean Icon is incapable of expressing the distinction. Whether it's more desirable or not, "while write(read())" is remarkably concise and looks simple. Also in Icon's favor, it's nice not to have to enumerate failure differences which are irrelevant to the situation. Everyone who ever complained about Java's checked exceptions knows what I mean. My reservations are about whether the concise idiom will make more complex cases harder to understand. I'm troubled by the example's implication that Icon is designed to silence exceptions by default, which is bad practice in any language.