Yes, I agree with you. catch/throw does seem better than using exceptions for everything. Python's infatuation with exceptions doesn't seem like the best course of action.
However, that does raise one question: should we have exceptions at all?
Note: I do actually want to use `err` in my program, because I want all execution to halt. I just want it to halt after all the errors are finished, rather than after only one error.
Perhaps I should use (quit) instead... does that automatically close any files opened by Arc?
Perhaps I should use (quit) instead... does that automatically close any files opened by Arc?
Yes. quit exits the process, and the operating system closes all open files when the process terminates.
However, that does raise one question: should we have exceptions at all?
We still do want a mechanism for reporting actual program errors. Things that are truly bugs. For example, a division by zero exception is always avoidable by not passing 0 as the divisor. I dislike using a try-catch mechanism in my program for checking for things like dividing by zero, because I end up catching other cases of dividing by zero that I didn't intend to, which are actual bugs. So if I expect I might have 0 as a divisor, I prefer to check for it explicitly before calling /. Thus (when I write programs the way I like to), any actual division by zero exceptions that get thrown are in fact actual bugs. Which I then want to capture and report with lots and lots and lots of debugging information.
