This feels to me like the best of all possible worlds, but I'm curious if it even makes sense to anyone else, or if someone has a better idea for how to handle error situations in code. Keep in mind I'm not looking for a solution to bolt into an existing language so much as a theoretical ideal.
Thoughts?

entrypoint :
{
    print(FallibleFunction(42, "Test"))
}
with handlers
{
    Barf : { print("Function barfed.") }

    Vomit : string reason -> integer fallback = 0
        { print("Vomit! Falling back to 0 becuase: " ; reason) }
}


FallibleFunction : integer p1, string p2 -> string ret = ""
{
    if(p1 > 100)
    {
        panic => Barf()
    }

    while(p1 > 20)
    {
        p1 = (panic => Vomit("Number slightly too high"))
    }

    ret = p2 ; " ... " ; cast(string, p1)
}

I feel like that sort of syntax would lead to a very tight coupling between the function and the protect block. You'd have to know within a function, who would be calling it, and the calling functions would have to know all the possible 'exceptions'. Having to specify all the 'exceptions' isn't hard for a single function, but once they start getting nested...

It doesn't seem practical to me. Outside of trivial examples I can't for the life of me think of a good example. Even in the case of say an invalid file name in a file handling function, looping on an exception or sentinel return value would be easier. This also looks to me to be a maintenance nightmare.

Clever, but I question its practicality. But just cause I can't see its use doesn't mean there isn't one. Any good examples come to mind? Ones that wouldn't be trivial to code using exception handling or sentinel return values?

I have a love/hate relationship with both of them. Both have their flaws. But ultimately I hate return codes less than I hate exceptions.

Think hard about why we have them. What are the reasons for return codes and exceptions?

Most error codes are about input validation problems.

No, seriously, take a look at things like the C errno values. Almost all of them are for conditions that should have been validated but were not. Argument list too long, permission denied, file exists, not a directly, is a directory, file too large, too many links, name too long, directory not empty, out of range, etc. These are all things that could have been caught by validation, but instead of doing they rely on the system do to it for them, and it fails with an error code. The same is true for Windows system error codes. File name too long, disk full, process not found, no children to wait for, invalid format, label too long, segment already locked, and on and on. True the rest of them are things you might not easily detect, but many of them are just a case of not validating your data.

So if you just validate your data you will solve the vast majority of your error conditions. Liberally cover the top of your functions with asserts to let programmers know they failed at the basic task of validating their inputs. Most of the time you don't need either exceptions or sentinel return values, just validate your own data.

Next, even though exceptions can provide additional information closer to the source of the error, they degrade back to error codes. Exceptions do provide graceful handling of a few things -- such as errors during a constructor (although that is very bad, write c'tors and d'tors to never throw or else never create an array) -- but they also lack grace in many situations by adding a large amount of error handling code and adding invisible exit points at every function call and operation. Also when an exception must cross a boundary -- such as a library boundary -- the exception invariably gets converted into a sentinel return value.

In searching for a supporting statement, I found Ramond Chen had an article about it that summed up my feelings nicely. Both are equally powerful in that they allow you to detect and handle error conditions. Exceptions do provide quite a few nice features like a call stack and unique messages along the way back up, but on the other hand they present many more opportunities for error. When everything relies on error codes it is very easy to tell when the code is using those values or not. One glance can tell you if it is following a chain where every return value is tested. But exception based code is a bit harder. Did they catch every significant exception? Did they catch them at the right point to avoid leaking resources? It is harder to see bad exception-based code than to see bad error-code-based code.

Seven decades of active use demonstrate that while return values can be ignored or misused, they can also be used very effectively.

I'm sorry I disagree Frob, I use exceptions almost exclusively, and it'd be a cold day in hell before I returned to return values.

Both return values and exceptions have the same amount of error handling code. The difference is with return values you must handle it at the function return point, with error code spread all over the place. With exceptions you can handle it where ever is the most convenient/easiest/least error prone to do so.

A proper exception hierarchy will also provide much more information, and be quicker and safer to expand, than an error code. Add a new error code to a function and anything that uses that function will have to be re-written. Add a new exception and only a few catch() blocks need to be updated.

Ignored exceptions are also easier to track. Ignored return value errors can cause the program to execute significantly past the point of error, corrupting memory along the way and making tracing the bug tedious. An ignored exception will halt the program, with a very informative stack output and all data up to the exception intact.

I also don't see why constructors throwing exceptions are a bad thing. That was one of the primary situations that exceptions were created for. Obviously exceptions in destructors are bad, but its not like you can return a return code from them either.

I know exceptions seem to get a lot of hate, but once I got used to them I fell in love. Its one of the few things I love about C++...

What you seem to be describing is a "warning" system that works in place of the "error" system that is exception. That is, you're creating a mechanism to continue on that's controlled at the call site. That's not really one of the 5 priorities you listed.

I think exceptions are much better than return codes, precisely because you can put the code to handle the exception case out of line of the normal path.

But exceptions do have their problems too. For example, sometimes you do want to handle the exception right at the call site, but exception syntax is very verbose for doing that. So you've traded brevity for flexibility.

But is the syntactic difference really that much?

a = GetNumber();
if (a == error_1) { /* handle error 1 here */ }
else if (a == error_2) { /* handle error 2 here */ }
else { /* handle everything else here */ }

vs

try { a = GetNumber(); }
catch (const Error1& e) { /* handle error 1 here */ }
catch (const Error2& e) { /* handle error 2 here */ }
catch (...) { /* handle everything else here */ }

I mean, I understand that prior to exceptions that the return value code would be clearer simply due to familiarity. But having used both, from a purely syntactic point of view, the difference is negligible. Only in the most simplest of cases are return values smaller:

if (!GetNumber()) {}

vs

try { GetNumber(); } catch(...) {}

That's about the only situation I can think of where return values are clearly tidier.

Perhaps there are situations I'm not aware of? When you say exception handling syntax is verbose what in particular are you thinking of?