On Thursday, 15 January 2015 at 19:37:33 UTC, Marc Schütz wrote:
Now, for a more generic library, you are right that using exceptions in this way is not a good idea. The crucial difference is IMO that in an MVC framework the application code is the one down the stack, while in many other applications it is further up the stack. Therefore, the use of exceptions (which always propagate upwards) have to be assessed differently.
FWIW, although the framework I use provides exceptions for returning HTTP status, I don't use them. I have my own super-class request handler that captures everything so that I can "reformulate" caught exceptions into something that fits the REST api I expose, which have to fit what browser support (like IE9)...
The only problem I see is if the "exception type system" lacks an ontology that the framework can rely upon.E.g. that a function pass the exception on, but mistakenly executes an action because it makes a classification mistake. But that is more a problem with having an inadequate/unspecified/fuzzy exception classification mechanisms...
The language could define an ontology that allows you to express "pass through unknown", "not a failure", "no rollback" or similar as part of the exception type. Finding the exact right semantics is perhaps tricky, but also an area where there is room for practical innovation.
