Er? Let's say you do a file operation, and want to catch if you get permission denied:

try { rm("fil"); } onerror (Error e) { if (e->permissiondenied) { werror("Permission denied when removing fil!\n"); break; //? } }

you also catch "out of memory", "out of stack", "no such file or directory", and probably a ton of errors I can't think of right now.

If the error isn't rethrown here, all those other errors will just go into the bit bucket, and your beard will grow white in the effort of tracing down that error that you caught but didn't report.

/ Mirar

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

If it's impossible to recover anyway, you don't catch the error in the first place...?

/ Mirar

Previous text:

2003-10-02 18:18: Subject: Re: throw or return

---

On Thu, Oct 02, 2003 at 05:40:02PM +0200, Mirar @ Pike developers forum wrote:

...

you also catch "out of memory", "out of stack", "no such file or directory", and probably a ton of errors I can't think of right now.

Then I will specify exactly what _types_ of errors I want to catch, so something irrelevent won't be handled.

But typically, if (say) I can't open a file, which is mandatory for application, I don't care _why_ it cannot be opened, I've to stop anyway (with message specifying the reason) - that's why I don't like this idea of implicit rethrowing.

Or similar situation with "division by zero" - it is impossible to recover anyway...

Regards, /Al

/ Brevbäraren

If you can do a customized action, that counts as a recover. You then *have* an alternative action if the first one failed...

/ Mirar

Previous text:

2003-10-02 18:35: Subject: Re: throw or return

---

On Thu, Oct 02, 2003 at 06:25:01PM +0200, Mirar @ Pike developers forum wrote:

...

If it's impossible to recover anyway, you don't catch the error in the first place...?

I do because (for instance) I want to provide customized action (like sending an email or printing a message to something different than stderr).

Regards, /Al

/ Brevbäraren

But typically, if (say) I can't open a file, which is mandatory for application, I don't care _why_ it cannot be opened,

Of course. Then you write an error handler that catches all open errors, not one for every specific reason. I don't see how that is relevant here.

I've to stop anyway (with message specifying the reason) /.../

So when you write the code that prints the message you also add a "break" afterwards to signify that the problem has been handled. What's the problem with that?

Note that if you can't continue in the function then the "break" would be e.g. "return" or "exit(1)" instead. Statements like that would not be superseded by a rethrow of the old error.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-10-02 18:18: Subject: Re: throw or return

---

On Thu, Oct 02, 2003 at 05:40:02PM +0200, Mirar @ Pike developers forum wrote:

...

you also catch "out of memory", "out of stack", "no such file or directory", and probably a ton of errors I can't think of right now.

Then I will specify exactly what _types_ of errors I want to catch, so something irrelevent won't be handled.

But typically, if (say) I can't open a file, which is mandatory for application, I don't care _why_ it cannot be opened, I've to stop anyway (with message specifying the reason) - that's why I don't like this idea of implicit rethrowing.

Or similar situation with "division by zero" - it is impossible to recover anyway...

Regards, /Al

/ Brevbäraren

Basically, the only problem that I see is implicity. If I want to rethrow or continue, I want to make it explicit,

Do you mean that you want it to always be an error when control reaches the end of the onerror clause? I.e. the user should always specify either rethrow or continue before that?

Something like "dismiss" and "escalate" would be more clear, IMHO.

There's some merit in that. The language shouldn't invite to doing the mistake I envisioned in an earlier example (10773358), so I agree the statement for continuing shouldn't be "break", at least.

Regarding "escalate", it's unnecessary. As Per pointed out, you can just as well write "throw(err)" for that.

If we have a special operator to handle error, the keywords must be special as well (or we have a problem - how to rethrow explicitly from inside of "for" loop, using "break" or "continue"?).

Then labels are used, just like when breaking or continuing any switch/for/while/do block that isn't the innermost one. You'd get the same problem with nested onerror clauses anyway, regardless of the chosen keywords.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-10-02 18:43: Subject: Re: throw or return

---

On Thu, Oct 02, 2003 at 06:35:02PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

So when you write the code that prints the message you also add a "break" afterwards to signify that the problem has been handled. What's the problem with that?

Basically, the only problem that I see is implicity. If I want to rethrow or continue, I want to make it explicit, and preferably without "continue" or "break" - just to make sure that those keywords won't be misinterpreted in case when someone forgot {} or so around "for", "while" or "switch".

Something like "dismiss" and "escalate" would be more clear, IMHO.

If we have a special operator to handle error, the keywords must be special as well (or we have a problem - how to rethrow explicitly from inside of "for" loop, using "break" or "continue"?).

Regards, /Al

/ Brevbäraren

I'd say the default in C++ (as well as in Java) is to rethrow since any exception that haven't got a handler is rethrown.

The difference from the construct we've been discussing here is that in those languages the test to match the exception is done through the type only, so that catch clauses are never even entered before the error is considered to match.

In Pike we want to have a more flexible system where we can write arbitrary code to do those tests. Thus the onerror clause is always entered and there's no way of knowing implicitly where the code that does the testing stops and that which does the actual handling starts.

That's why it's necessary to consider errors as unhandled when they enter the onerror clause and to have some statement to explicitly tell that they are to be considered handled.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-10-02 19:25: Subject: Re: throw or return

---

On Thu, Oct 02, 2003 at 07:05:04PM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

reaches the end of the onerror clause? I.e. the user should always specify either rethrow or continue before that?

I am not sure now... :) Initially I'd like explicit decision in any case, but now... After some thinking... Just not sure. I like the model in C++, where the default is "handled" (hence no rethrow), but all this just needs some thinking... A bit more...

Regards, /Al

/ Brevbäraren

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