I finally remembered this morning that Arc already does have a mechanism for passing a value up through multiple layers of code execution by using continuations: point (and the derived macro catch/throw).
point can be used in the kind of situation that you might want to use Racket's raise for. In fact, you can think of point as a macro that creates a "raise" function.
Python doesn't have continuations, so the only way to break out of multiple layers of function calls at once is by catching and throwing an exception.
There are situations where something happens in a program that we expect to happen (at least sometimes), and we need to stop doing what we're currently doing and start doing something else, and often pass some data along that we need.
However, I noticed in production code written in Python where throwing and catching an exception is used to implement this, it's not uncommon for the implementation to also catch other exceptions that the programmer didn't expect... leading to real errors arising from bugs not being reported.
So I think for this scenario at least, using point/catch/throw is a better mechanism because it's explicitly only catching the things you plan to throw, and thus leaves handling unexpected conditions (things you didn't plan for, and so are actual bugs in your program) to the error handling mechanism, where you want debugging information like the source code line location and so on.
Which in turns leads me to suspect that perhaps errsafe is the wrong choice for handling errors opening a file... but that would be the subject of a different post :)
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.
