Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error, Exception: clarify, document, fix (or just get rid of Exception) #9377

Closed
kevmoo opened this issue Mar 22, 2013 · 11 comments
Closed

Error, Exception: clarify, document, fix (or just get rid of Exception) #9377

kevmoo opened this issue Mar 22, 2013 · 11 comments

Comments

@kevmoo
Copy link
Member

@kevmoo kevmoo commented Mar 22, 2013

Per discussion: https://groups.google.com/a/dartlang.org/d/topic/misc/lx9CXiV3o30/discussion

Perhaps this can be split out into a number of issues/work items.

  1. Define the difference.
  2. Update doc comments for Error/Exception
  3. Reconsider subclasses in dart:core to algin with recommendation. Future.
      ... and dart:async: AsyncError, onError, immediateError, etc
  4. Update language guides, idiomatic dart doc, etc.

* Also consider that the distinction is too amorphous and these concepts should be combined. Given what I've heard, I'd almost argue for the Exception base class to go away and everything be Errors.

@DartBot
Copy link

@DartBot DartBot commented Mar 22, 2013

This comment was originally written by @jwendel


I would vote for just for better documentation. I like the distinction between Exception and Error, as it can be useful if you understand the differences.

Though, after programing in Java for a number of years, a number of people that casually code in the language don't understand the difference between the Exception and Errors, so it seems these people just treat both type of Throwables as the same thing.

@DartBot
Copy link

@DartBot DartBot commented Mar 22, 2013

This comment was originally written by @tatumizer


+1 for eliminating distinction. One app's error is another app's exception, and vice versa.

@madsager
Copy link
Contributor

@madsager madsager commented Mar 25, 2013

Removed Area-Language, Component-Docs labels.
Added Area-Library, Triaged labels.

@DartBot
Copy link

@DartBot DartBot commented Jun 26, 2013

This comment was originally written by off...@mikemitterer.at


... or get rid of Error :-) - I think people are more used to Exceptions than Errors

@lrhn
Copy link
Member

@lrhn lrhn commented Oct 14, 2013

It's probably a little late to remove Exception (because it's already being used), but I guess we could document that you shouldn't use Exception and hope that it is enough.

In Dart, anything can be thrown [1].
I don't mind having a type for errors, which are serious problems that shouldn't happen in properly written code. You may want to handle these specially, and we have added the ability to get a stacktrace from the object itself, just to make some kines of debugging easier.

But extending Exception gives you nothing. In fact, just by being there it may make people extend it anyway, which means that you can't have any idea which classes may be caught by a "catch Exception". Which makes "catch Exception" useless.

Non-error exceptions are intended to used as alternative return values - for handling exception cases that the user can't predict or prepare for, but that they probably want to handle (instead of letting the program crash).
It makes much more sense if each library that has such returns will define its own exception classes, and event their own hierarchy of related exceptions. Extending Exception isn't necessary for that, so the Exception type really doesn't carry its own weight.

[1] Except null. Historically it was considered too confusing that null was assignable to String, but "catch (String e)" didn't catch null.


Removed Type-Defect label.
Added Type-Enhancement label.

@floitschG
Copy link
Contributor

@floitschG floitschG commented Oct 14, 2013

Errors and Exceptions are different.
Errors happen because of incorrect use of the library; exceptions because of unexpected situations (despite using the library correctly).
The main difference is in how the situation is reported: errors are for humans, exceptions are (or should be) handled by the program. Our current exceptions are not perfect in that regard, but they should contain easily accessible information that allows to deal with the exceptional case.

We already have the Exception class. There is no point in removing it. It currently doesn't buy you anything to extend it, but on the other hand it doesn't hurt either.
I consider it good style to extend/implement Exception for Exception classes.

@DartBot
Copy link

@DartBot DartBot commented Oct 15, 2013

This comment was originally written by luoyon...@gmail.com


get rid of Error is my vote, Error is more restrict than Exception, we can assume different level of exception, unrecoverable is Error. For each exception there is a level tag such as fatal, error, failure normal, info

@DartBot
Copy link

@DartBot DartBot commented Oct 15, 2013

This comment was originally written by off...@mikemitterer.at


If you have to read documentation and forum entries just to know what the difference is between errors and exceptions then there is something wrong! If you throw Errors out it's a relative small step compared to all the discussions you'll have in the future about this topic.

@kevmoo
Copy link
Member Author

@kevmoo kevmoo commented Oct 15, 2013

Is there any way to get a StackTrace into Exception, though?

That's the killer for me.

In general I will always extend Error, regardless of the semantics your outline, because I always want a stack trace.

When I'm debugging some crazy Async code, I don't care if the design is for a human or a program -- I just want to figure out what broke.

@kevmoo
Copy link
Member Author

@kevmoo kevmoo commented Jan 18, 2014

Getting rid of Exception is out of the question now that V1 has shipped.

Opening another issue to track documenting the Error class.


Added WontFix label.

@kevmoo
Copy link
Member Author

@kevmoo kevmoo commented Jan 18, 2014

New issue tracking documentation for Error class - https://code.google.com/p/dart/issues/detail?id=16192

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants