You are absolutely right. The exception objects are an orthogonal issue to how to trap them. On the whole I think your suggestion looks fairly good. The compatibility implications of changing the current ({ "error", backtrace() }) de facto standard into an object based one is probably acceptable.
/ Martin Nilsson (saturator)
Previous text:
2003-10-01 18:40: Subject: Re: throw or return
On Wed, Oct 01, 2003 at 06:15:01PM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
I would favor a solution where "catch" didn't have to change semantics.
would it be better to return something more meaningful when throwing an error? Some universal object with methods to determine error type, error locus and exact error code (and suggested action perhaps)?
Like:
if ((err = catch(func())) && err->type != "user") throw(err); // Pass it on if we can't handle
Other methods:
err->locus -- may replace backtrace (or point to location like "filesystem" or "cpu" for divison by zero err->errno -- in case when type == "system" err->action -- may be "retry" (for transient errors), "abort" (for fatal errors), "ignore" (like file doesn't exist when unlinking or another safe-to-ignore error), etc err->code -- exact error code (if applicable and not OS related) Error types might be "os" or "system" (for system calls and related objects), "user" (classic throw() with custom message/code), "pike" (interpreter itself, like dereferencing a mapping which is NULL), and so on... In this case we don't need to change anything in syntax, not so much, at least.
Regards, /Al
/ Brevbäraren