With enough flexibility there's no easy way to know whether an error is considered to be handled or not. A naive system would consider an error handled as soon as it reaches any code in the onerror clause, but that code might actually only do further tests to decide whether to handle it or not. That's why it's better to always rethrow unless a statement explicitly says not to.
In a switch-like statement there'd be breaks after each clause anyway, so if those breaks disables rethrow then there's no need for extra statements for that. Actually, it's a bit of a problem since people might forget that the break blocks rethrows. For example:
try do_stuff(); onerror (Error err) { case err->is_io_error: if (err->file == my_file) { // Ok, it's a problem concering our file. We want to handle this. handle_file_error (err, my_file); break; // We're done, let's continue. } break; // Just a normal break to avoid fall-through to the next clause. // Oops, it accidentally blocks rethrow of all I/O errors!
case err->is_some_other_error: .... }
Besides, it's not that uncommon with code that is run for errors and rethrows them. I've often written such things that adds extra info to the error message.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-02 17:34: Subject: Re: throw or return
On Thu, Oct 02, 2003 at 05:25:03PM +0200, Mirar @ Pike developers forum wrote:
Exactly. And since Pike programmers almost by definition are lazy, lets make the default behaviour what you almost always want to do, that is rethrow the error...? :-)
Uhm... It seems logical, but... it is a bit unlogical... As I said before, there is no point to handle an error to rethrow it... Perhaps it makes sense to invent some mandatory statement to explicitly specify an action - say, rethrow or escalate and dismiss. Using of break and continue is bad option, IMHO...
Regards, /Al
/ Brevbäraren