digitalmars.D.learn - Exception vs. Error
- Lionello Lunesu (13/13) Mar 26 2007 What's the difference between an Exception and an Error?
- Sean Kelly (18/30) Mar 26 2007 Personally, I don't see any point in having the Error class, for the
- Lionello Lunesu (3/37) Mar 26 2007 This makes a lot of sense :) Thanks, Sean, for your take on this.
- Stewart Gordon (34/45) Mar 29 2007 OUAT there was some discussion about tidying up the error/exception
- Don Clugston (4/27) Mar 29 2007 Yes, I think the only sensible distinction is between 'this is
- Sean Kelly (37/48) Mar 29 2007 I don't think it would. If Errors are not recoverable, then that
-
Stewart Gordon
(10/17)
Mar 30 2007
What's the difference between an Exception and an Error? I know that Exceptions are meant to be recoverable and Errors are non-recoverable, but this doesn't help me since (1) Error is derived from Exception (so any catch(Exception) can _recover_ from an Error), and (2) there are also many catch(Error) which seems that an Error is not quite that bad. Take Phobos for example. Why are some problems throwing an Error and others an Exception? In either case, it seems like the Error class should not derive from the Exception class, since catching one should not consume the other. Who has some clue what's going there? L.
Mar 26 2007
Lionello Lunesu wrote:What's the difference between an Exception and an Error? I know that Exceptions are meant to be recoverable and Errors are non-recoverable, but this doesn't help me since (1) Error is derived from Exception (so any catch(Exception) can _recover_ from an Error), and (2) there are also many catch(Error) which seems that an Error is not quite that bad.Personally, I don't see any point in having the Error class, for the reasons mentioned above. The only useful thing about Error is that it contains file and line info, and errors can be chained. In Tango, these features have been added to Exception and Error has been dropped.Take Phobos for example. Why are some problems throwing an Error and others an Exception?Your guess is as good as mine.In either case, it seems like the Error class should not derive from the Exception class, since catching one should not consume the other.Right. And then there's the issue of what is actually recoverable. Personally, I think this varies based on the type of application being written. As a result, I don't think the language should dictate that some errors are recoverable and other ones are not. Rather, the exception hierarchy should be designed so that errors which are typically not recoverable can not be easily ignored, and the rest is up to the user. I tried this in Tango by making all such errors direct descendants of Exception (because everything thrown in D is supposed to derive from Exception) and suggesting rather strongly that "catch Exception" is generally an error and should never be done by the average user. Sean
Mar 26 2007
Lionello Lunesu <lio lunesu.remove.com> Sean Kelly wrote:Lionello Lunesu wrote:This makes a lot of sense :) Thanks, Sean, for your take on this. L.What's the difference between an Exception and an Error? I know that Exceptions are meant to be recoverable and Errors are non-recoverable, but this doesn't help me since (1) Error is derived from Exception (so any catch(Exception) can _recover_ from an Error), and (2) there are also many catch(Error) which seems that an Error is not quite that bad.Personally, I don't see any point in having the Error class, for the reasons mentioned above. The only useful thing about Error is that it contains file and line info, and errors can be chained. In Tango, these features have been added to Exception and Error has been dropped.Take Phobos for example. Why are some problems throwing an Error and others an Exception?Your guess is as good as mine.In either case, it seems like the Error class should not derive from the Exception class, since catching one should not consume the other.Right. And then there's the issue of what is actually recoverable. Personally, I think this varies based on the type of application being written. As a result, I don't think the language should dictate that some errors are recoverable and other ones are not. Rather, the exception hierarchy should be designed so that errors which are typically not recoverable can not be easily ignored, and the rest is up to the user. I tried this in Tango by making all such errors direct descendants of Exception (because everything thrown in D is supposed to derive from Exception) and suggesting rather strongly that "catch Exception" is generally an error and should never be done by the average user.
Mar 26 2007
"Lionello Lunesu" <lio lunesu.remove.com> wrote in message news:eu87lp$2g7p$1 digitalmars.com...What's the difference between an Exception and an Error? I know that Exceptions are meant to be recoverable and Errors are non-recoverable, but this doesn't help me since (1) Error is derived from Exception (so any catch(Exception) can _recover_ from an Error), and (2) there are also many catch(Error) which seems that an Error is not quite that bad.OUAT there was some discussion about tidying up the error/exception hierarchy. But "recoverable" depends on your POV. What sense does it make to set this in stone? Some applications may be able to recover from a given error, whereas others can't. AISI there are three kinds of errors: (a) runtime checks in development builds, which are removed in release builds (AssertError, SwitchError, ArrayBoundsError) (b) errors that stay in release builds, but which correctly-working applications should never throw (e.g. FormatError) (c) errors that are generally beyond the programmer's control (e.g. file system errors, out of memory) Whether something should count as (b) or (c) is also debatable. Suppose you have a date formatting function that accepts a format string (like in my utility library). Applications that use this will typically supply this format string, and users of it in this way will likely see it as an error of kind (b). But an application may also allow the user to supply a format string, which is then passed directly to the library function - it then becomes (c).Take Phobos for example. Why are some problems throwing an Error and others an Exception? In either case, it seems like the Error class should not derive from the Exception class, since catching one should not consume the other.You're probably right. I'm wondering whether it would make sense for Exception to derive from Error. Java has a class Throwable, from which Exception and Error are derived. But that could be partly because Java methods must explicitly declare what exceptions they may throw other than RuntimeException. So basically, the way this works is that every method is implicitly declared to throw RuntimeException and Error. In D, you can throw an object of any class, but having a common base class for exceptions and errors is still useful as it enables some of the workings to be shared. At the moment it's really just the exception message and hence toString, but who knows if it'll eventually have stuff like getting a stack trace? What is the 'next' member of Error for? Phobos doesn't seem to use it at all. Stewart.
Mar 29 2007
Stewart Gordon wrote:"Lionello Lunesu" <lio lunesu.remove.com> wrote in message news:eu87lp$2g7p$1 digitalmars.com...Yes, I think the only sensible distinction is between 'this is DEFINITELY a bug', and 'this is a situation I don't know how to deal with', rather than 'recoverable'/'unrecoverable'.What's the difference between an Exception and an Error? I know that Exceptions are meant to be recoverable and Errors are non-recoverable, but this doesn't help me since (1) Error is derived from Exception (so any catch(Exception) can _recover_ from an Error), and (2) there are also many catch(Error) which seems that an Error is not quite that bad.OUAT there was some discussion about tidying up the error/exception hierarchy. But "recoverable" depends on your POV. What sense does it make to set this in stone? Some applications may be able to recover from a given error, whereas others can't. AISI there are three kinds of errors: (a) runtime checks in development builds, which are removed in release builds (AssertError, SwitchError, ArrayBoundsError) (b) errors that stay in release builds, but which correctly-working applications should never throw (e.g. FormatError) (c) errors that are generally beyond the programmer's control (e.g. file system errors, out of memory)
Mar 29 2007
Stewart Gordon wrote:You're probably right. I'm wondering whether it would make sense for Exception to derive from Error.I don't think it would. If Errors are not recoverable, then that suggests that Exceptions would not be recoverable as well. The reverse problem holds when Exception derives from Error.Java has a class Throwable, from which Exception and Error are derived.We considered this for Tango, but decided against it because it still strictly defines what is and is not a recoverable error based on which parent class is chosen. For common applications this might be fairly straightforward, but things are less clear-cut when designing an operating system kernel, for example. As a systems programming language, I feel that D can't make the same assumptions that Java typically can.In D, you can throw an object of any class, but having a common base class for exceptions and errors is still useful as it enables some of the workings to be shared. At the moment it's really just the exception message and hence toString, but who knows if it'll eventually have stuff like getting a stack trace? What is the 'next' member of Error for? Phobos doesn't seem to use it at all.Tango has these in Exception, and they are intended for something like this: void fnA() { try { fnB(); } catch( Exception e ) { throw new Exception( "Call failed with: ", e ); } } void fnB() { throw new Exception( "Danger, Will Robinson!" ); } In essence, there are times when an enclosing routine can't entirely recover from an exception it catches, and it may occasionally be useful to re-categorize the exception or to provide additional information, but also to retain the original exception for later inspection. One example might be a low-level IO failure that causes in a cascade of failures up the call stack. At some high level the user code might catch and handle a LoginFailureException, but that might include a chain of: InvalidProtocolException, InvalidSocketStateException, and CorruptSocketBufferException. Sean
Mar 29 2007
"Sean Kelly" <sean f4.ca> wrote in message news:euh89g$665$1 digitalmars.com...Stewart Gordon wrote:<snip> Not necessarily. An Error could be defined as simply an error, not as recoverable or unrecoverable. And Exception would then be a particular kind of error: one that's recoverable. But still, with what you go on to say (and what I had begun to say) about recoverability depending on your point of view, maybe there isn't much point trying to classify them. Stewart.You're probably right. I'm wondering whether it would make sense for Exception to derive from Error.I don't think it would. If Errors are not recoverable, then that suggests that Exceptions would not be recoverable as well. The reverse problem holds when Exception derives from Error.
Mar 30 2007