On 2012-02-19 17:29, Andrei Alexandrescu wrote:
On 2/19/12 9:56 AM, Nick Sabalausky wrote:
"Andrei Alexandrescu"<[email protected]> wrote in message
news:[email protected]...
On 2/19/12 5:22 AM, deadalnix wrote:
Le 19/02/2012 08:05, Andrei Alexandrescu a écrit :
How about a system in which you can say whether an exception is I/O
related, network related, recoverable or not, should be displayed
to the
user or not, etc. Such is difficult to represent with inheritance
alone.
That may sound great on the paper, but it isn't. The fact that an
exception is recoverable or not depend often on your program and not on
the cause of the exception.
This is self-evident. Again, the meaning of "recoverable" is "operation
may succeed if retried with the same input". It's a hint for the catch
code. Of course the program is free to ignore that aspect, retry a
number
of times, log, display user feedback, and so on. But as far as
definition
goes the notion is cut and dried.
WTF? "Recoverable" means "can be recovered from". Period. The term
doesn't
have a damn thing to do with "how", even in the context of exceptions. It
*never* has. If you meant it as "operation may succeed if retried with
the
same input", then fine, but don't pretend that *your* arbitrary
definition
is "cut and dried".
I think it's a reasonable definition of "can be recovered from" in the
context of exceptions.
No it's not. Say you want to save a file. You're saving it in "/" which
you don't have permission to write to. The system throws an exception
PermissionException, this is a recoverable exception since the
application could prompt the user to save the file in a different location.
--
/Jacob Carlborg
