/.../ and most of the time there shouldn't be any error. (Right?)
There could be applications that throw some errors fairly frequently, so speed can't be ignored. Anyway, with the option to resort to the err->is_my_error variety, the type comparisons can always be avoided when performance is very important.
True.
A combination could work too, so you can put the declaration at "try" once and for all if you're in that mood,
Possible, but I'm not sure it's worth the proliferation in syntax varieties just to save a little bit of typing. To that end I suggest to start only with the syntax where the declaration is in each catch clause and extend with the other one later on if people find it really annoying.
Agreed, it would also lead to the exception object having the expected scope.
If the typesystem can't support this, however, the branch of discussion goes to the bitbucket. :)
Indeed. I leave that to the undisputed authority on the pike type system, namely Grubba. ;)
I guess that's my cue.
Mast's suggested syntax:
try_statement: TOK_TRY block catch_list ;
catch_list: catch_statement | catch_list catch_statement ;
catch_statement: TOK_CATCH ( type optional_identifier ) block_or_semi ;
Is easy to generate code for:
if (mixed __err__ = catch { BLOCK }) { if (_typeof(__err__) <= TYPE) { TYPE OPTIONAL_IDENTIFIER = [TYPE] __err__; BLOCK_OR_SEMI } else if (...) { ... } else throw(__err__); }
I don't however see any immediate need for the syntax in the complex case:
try { ... } catch (object err; err->is_my_error && err->failure_pos > 4711) { ... }
which could just as well be written as:
try { ... } catch (object err) { if (err->is_my_error && err->failure_pos > 4711) { ... } else throw(err); }