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