HaloO,
Yaakov Belch wrote:
I believe that ---from a usability point of view--- it's very important to:
* classify exceptions by "severity" or other characteristics,
* provide named adverbs/pragmas to modify default CATCH handlers,
* make them configurable by "outer scopes".
> [..]
The programmer of the top-level function defines the severity of
particular exception groups for this specific application by defining named
CATCH handlers.
I want to propose---possibly again ;)---to use the dispatch
semantics for this purpose. The idea is that CATCH blocks
can be made into multis first of all with the multi keyword
or with a proto which then makes inner CATCH blocks also multi
unless they are explicitly declared only.
Generally speaking I find multiple CATCH blocks with a signature
better than a big switch inside a single one. Such a CATCH without
signature would be good for low-level handling, though. It has
implicit signature :(Any) and is easily overridden from outer
scopes.
The grouping comes naturally since packages are recognized as
type names. So we can have
proto CATCH {...} # force multi
{
multi CATCH (Math::DivZero) {...}
{
multi CATCH (Math) {...}
multi CATCH (Math::Overflow) {...} # more specific
# outer catch seen here as well
{
CATCH
{
when Math {...} # never called
}
}
}
}
And if we really go so far, we can have standard names for two
CATCH handlers: "CATCH://" and "CATCH:orelse".
So with CATCH a magic namespace these would be CATCH::<//> and
CATCH::<orelse> respectively. Using the namespace is another
approach. But to me it doesn't feel as natural as the exception
type approach.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
