> the PL/I method was to group the error handlers at the end and pass the labels of the error handlers to the invoked function as alternative return labels.
The idea of an alternative return address - that is, allow the calling convention to pass more than on return instruction pointer - seems both simple to implement and really useful. I guess in the modern gotoless world the trouble is structuring the syntax around the call.
The alternative return addresses were declared in the function prototype as parameters having the type label.
Then you just passed them during function call, e.g. "handle = open_file(input_file_name, open_flags, FailedToOpenInputFile);"
The error handlers at the end of the body of the invoking function were just labelled appropriately.
Writing a label like FailedToOpenInputFile: before an error handler is certainly much simpler and more obvious than strange workarounds for exception identification, like inventing a dedicated data type for each possible error, as in C++.
It would be nice if those labeled blocks could be written inline and anonymously - just pass a block as an argument rather than having to actually name the error handling block. Is that supported?
It depends on which part of code will clear stack after call. If caller is responsible to clear stack, like in C, to support variable arguments, then called function must return to the original point of call.
If called function is responsible to clear stack, like in Pascal or Forth, then yep, multiple return points are easy to implement and useful to implement something like switch operator. I used it in Pascal, when I was in school. Just pop old return address from stack and push new one.
You are right, but the ancient cdecl function call convention used by C for variable argument lists is really obsolete and it should never be used in any new programming language implementation, even if it has survived until today in various ABI specifications.
Like for the C null-terminated strings, there are many alternative ways to implement variable argument lists and all of them have already been used many years before the first C compilers, e.g. passing a hidden parameter count or implementing transparently for the programmer any printf-like functions as vprintf-like functions.
With the alternative implementations, the stack should always be freed in the invoked function, which also enables various other important features, e.g. tail-call optimization.
The idea of an alternative return address - that is, allow the calling convention to pass more than on return instruction pointer - seems both simple to implement and really useful. I guess in the modern gotoless world the trouble is structuring the syntax around the call.