What about: "try{} onError {} onSuccess {}"? #6047
Comments
|
This comment was originally written by thesaint198...@gmail.com Ah damn... You also need to add the general catch: catch(e) { c(); throw; } Then it should work. |
|
This comment was originally written by thesaint19...@gmail.com Damn I hate it that you can edit your posts... Above please replace "finalize" with "finally", or it makes no sense. |
|
Set owner to @gbracha. |
|
Regarding comment 1: catch(e) {...} is already legal. Regarding the substance: the only difference between catch(e){handleErrror()} and onError{handleError()} is the need to specify a name for the exception. Use _ if typing/inventing names is too hard, and use dontCare or anyError if you are really serious about conveying intent. This does not rise to the level of a language feature. As for the onSuccess scenario - its not that hard to deal with. Error handlers need to throw or return, and the success scenario can be given after the try. Added Accepted label. |
DartBot
added
Type-Enhancement
area-language
kevmoo
added
P2
|
This is a neat idea, but our impression is that it doesn't carry its weight. Any language feature starts out "in debt"—it must be implemented, tested, documented, debugged, learned, and maintained. Users must know it when they run into it in each other's code. It occupies a portion of the grammar that we'll never be able to use for anything else, and it adds some complexity to the language that will never be subtracted. Features win by adding a large enough value to pay off that debt, but the sad reality is that most feature ideas don't make it. Given that you can pretty easily workaround this one by reorganizing your code a little or hoisting some code into a separate helper function, we don't think this one pays for itself. |
munificent
added
the
closed-not-planned
This issue was originally filed by thesain...@gmail.com
From: https://groups.google.com/a/dartlang.org/forum/?fromgroups=#!topic/misc/wvxMt2NQuaM
I just often ran into the issue that I don't care that an exception was thrown, I just want to do some "on-error" code before leaving the scope. Currently you can do this ala "catch(Exception e) { doSomething(); throw; }". But this does not reveal its intention. What I wanted to do was "onError{ doSomething(); }"...
While we are at it. Another situation that I encounter often enough is the opposite. I have code that runs in "onError", but then I don't want to invoke finally. But I want to invoke finally when no error has occured. That gets even more convoluted with the current "inherited" exception scheme.
So what I am proposing is to introduce "onError" and "onSuccess" as new members of the "try" family. I am not 100% sure but I recall that Visual Basic already has this.
So
try{ a(); } on ArgumentException (e) { b(); } onError { c(); } on OverflowException (e) { d(); } onSuccess { e(); }
would translate to something like:
bool hasError = true;
try{
a();
hasError = false;
} on ArgumentException catch(e)
{
b();
c();
} on OverflowException catch(e)
{
c();
d();
} finally
{
if(!hasError) e();
}
Hmm I hope that is correct, but you get the idea.
The text was updated successfully, but these errors were encountered: