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.

This comment was originally written by @tatumizer

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

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

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

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

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.

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.

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

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.

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.

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.

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