-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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. |
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]. 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). [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. |
Errors and Exceptions are different. 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. |
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 |
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.
... and dart:async: AsyncError, onError, immediateError, 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.
The text was updated successfully, but these errors were encountered: