[dart-misc] Try / Catch proposal

[Felipe]

I would like to do this in Dart.

Now:

void myFunction(){
try {
....
} catch (e) {
....
}finally{
....
}
}


Proposal (I think for many situations is cleaner)

void myFunction(){
....
} catch(e){
....
} finally{
....
}


Thanks ;)

[Cristian Garcia]

+1 Nice!

Post by Felipe
I would like to do this in Dart.
void myFunction(){
try {
....
} catch (e) {
....
}finally{
....
}
}
Proposal (I think for many situations is cleaner)
void myFunction(){
....
} catch(e){
....
} finally{
....
}
Thanks ;)
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Cristian Garcia]

Should this only apply to "actions" (void functions)?

Post by Cristian Garcia
+1 Nice!

Post by Felipe
I would like to do this in Dart.
void myFunction(){
try {
....
} catch (e) {
....
}finally{
....
}
}
Proposal (I think for many situations is cleaner)
void myFunction(){
....
} catch(e){
....
} finally{
....
}
Thanks ;)
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Felipe]

To functions and methods, void or not. It was just one example.

['Lasse R.H. Nielsen' via Dart Misc]

When I see a specific feature like this, I try to see if it generalizes.
Whether it does or not tend to be enlightening :)

What if *any* block could have a catch/finally.

It sounds more general ... but it turns out, all that all it does is to
remove the "try" from a try/catch/finally statement. It may be slightly
shorter, but lacks the leading hint that something is wrapping the
following block (all special blocks have leading syntax, "for", "while",
"do", "try", "catch", "finally").
Uniquely among these, the "try" actually isn't necessary (the "do" is
because otherwise {stmts} while (expr); would be a block statement followed
by an empty while).

A function body isn't *exactly* a block statement, but it's close enough
that if we remove "try" and make "catch/finally" a possible suffix of a
block statement, it could generalize to function bodies.

So what would we lose?
One thing is that the entirety of a function's body is no longer inside an
outer block. That means parser complications - the "catch(e)" after a
method must not be seen as a new function declaration. Since "catch" is a
reserved word, that's probably not a problem.
It will be slightly harder to read for people trained to find the matching
"}" and assume the function ends there (and ditto tools).

What is the variable scope of those extra blocks? It would be reasonable
that they are in scope of the function parameters. So far a "(var x) {
stmts; }" has only had the scope of "x" extend to the following block. It's
not a big problem to have it also extend to more blocks, but it is a slight
idiosyncrasy that might trip people up.

So, all in all, it adds a bunch of small differences from other languages
and other parts of Dart in order to save "{ try" and "}" (and some
whitespace).
I'm not sure it's actually worth it (even if I personally think "try" is
ugly and annoying). If anything, I'd remove the need for "try" inside the
function, and still require you to wrap it in an outer "{" and "}" body
delimiter.


/L

Post by Felipe
I would like to do this in Dart.
void myFunction(){
try {
....
} catch (e) {
....
}finally{
....
}
}
Proposal (I think for many situations is cleaner)
void myFunction(){
....
} catch(e){
....
} finally{
....
}
Thanks ;)
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[ravi teja]

For:

1) It removes annoying indentation caused by try/catch. This point only
matters for complex functions. When you have too many indentations and you
split the screen, using the horizontal scroll bar could be very annoying.

Against:

1) It would be weird to have access to variables from main block in catch
and finally blocks. To people who are familiar with C-like languages, only
variables from current scope and scopes above could be used. This looks
like it gives access to sibling scopes.



On 21 August 2015 at 09:41, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
When I see a specific feature like this, I try to see if it generalizes.
Whether it does or not tend to be enlightening :)
What if *any* block could have a catch/finally.
It sounds more general ... but it turns out, all that all it does is to
remove the "try" from a try/catch/finally statement. It may be slightly
shorter, but lacks the leading hint that something is wrapping the
following block (all special blocks have leading syntax, "for", "while",
"do", "try", "catch", "finally").
Uniquely among these, the "try" actually isn't necessary (the "do" is
because otherwise {stmts} while (expr); would be a block statement followed
by an empty while).
A function body isn't *exactly* a block statement, but it's close enough
that if we remove "try" and make "catch/finally" a possible suffix of a
block statement, it could generalize to function bodies.
So what would we lose?
One thing is that the entirety of a function's body is no longer inside an
outer block. That means parser complications - the "catch(e)" after a
method must not be seen as a new function declaration. Since "catch" is a
reserved word, that's probably not a problem.
It will be slightly harder to read for people trained to find the matching
"}" and assume the function ends there (and ditto tools).
What is the variable scope of those extra blocks? It would be reasonable
that they are in scope of the function parameters. So far a "(var x) {
stmts; }" has only had the scope of "x" extend to the following block. It's
not a big problem to have it also extend to more blocks, but it is a slight
idiosyncrasy that might trip people up.
So, all in all, it adds a bunch of small differences from other languages
and other parts of Dart in order to save "{ try" and "}" (and some
whitespace).
I'm not sure it's actually worth it (even if I personally think "try" is
ugly and annoying). If anything, I'd remove the need for "try" inside the
function, and still require you to wrap it in an outer "{" and "}" body
delimiter.
/L

Post by Felipe
I would like to do this in Dart.
void myFunction(){
try {
....
} catch (e) {
....
}finally{
....
}
}
Proposal (I think for many situations is cleaner)
void myFunction(){
....
} catch(e){
....
} finally{
....
}
Thanks ;)
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

On Fri, Aug 21, 2015 at 12:41 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
When I see a specific feature like this, I try to see if it generalizes.
Whether it does or not tend to be enlightening :)
What if *any* block could have a catch/finally.

This is how Ruby works. There is no "try" form. Instead, you can add a
rescue clause to any block form. I think even class definitions allow it
since they contain imperative code.

Post by 'Lasse R.H. Nielsen' via Dart Misc
It sounds more general ... but it turns out, all that all it does is to
remove the "try" from a try/catch/finally statement. It may be slightly
shorter, but lacks the leading hint that something is wrapping the
following block (all special blocks have leading syntax, "for", "while",
"do", "try", "catch", "finally").

Well, block statements don't have a leading keyword. :)

I think the idea is to not think of it as *wrapping* the following block
but as being a property of the block itself.

Post by 'Lasse R.H. Nielsen' via Dart Misc
A function body isn't *exactly* a block statement, but it's close enough
that if we remove "try" and make "catch/finally" a possible suffix of a
block statement, it could generalize to function bodies.
So what would we lose?
One thing is that the entirety of a function's body is no longer inside an
outer block. That means parser complications - the "catch(e)" after a
method must not be seen as a new function declaration. Since "catch" is a
reserved word, that's probably not a problem.

The spooky one is our funny catch syntax where you can omit the catch
clause:

foo() {
...
} on Bar {
...
}


I can't come up with any actual ambiguity, but it's close enough (this
almost defines a second function Bar that returns an on) to make me worried
about later language additions.

Post by 'Lasse R.H. Nielsen' via Dart Misc
It will be slightly harder to read for people trained to find the matching
"}" and assume the function ends there (and ditto tools).
What is the variable scope of those extra blocks? It would be reasonable
that they are in scope of the function parameters. So far a "(var x) {
stmts; }" has only had the scope of "x" extend to the following block. It's
not a big problem to have it also extend to more blocks, but it is a slight
idiosyncrasy that might trip people up.
So, all in all, it adds a bunch of small differences from other languages
and other parts of Dart in order to save "{ try" and "}" (and some
whitespace).
I'm not sure it's actually worth it (even if I personally think "try" is
ugly and annoying). If anything, I'd remove the need for "try" inside the
function, and still require you to wrap it in an outer "{" and "}" body
delimiter.

From the purist standpoint, I like the idea of allowing any block (or
member body) to have a catch clause and remove the special try construct.

In practice, though:

- try blocks aren't actually that common. Exceptions are thrown far more
often than they are caught. (The majority of exceptions are programmatic
errors whose intent is to kill the program with a helpful stack trace.)

- Users coming from C++, Java, C#, and JS are familiar with a try form.

Given those, I don't think this is the best place for Dart to try to
innovate.

Cheers!

[tatumizer-v0.2]

There's one area where innovation won't hurt: adding context to exceptions.
Very often, exception is caught just to wrap it in another exception (with
more context information) and then re-throw. This is ugly. Instead, it
would be nice to have something like a function
onException((e)=>e.addContext("user $userName");
(naturally, when function(block) exits, all onException() handlers are
cleaned up automatically)

Currently, this is a major use case for "catch" Whoever doesn't want to add
catch to every function, adds a lot of logging instead. Some do both.
Program quickly becomes unreadable. Log files are getting huge and require
special tools to make any sense of them - though most of the time, you need
detailed info only if exception occurs.

P.S. Probably, this thing can be generalized to cover more use cases. E.g.
onReturn((v)=>print("returning $v from foo"); // triggered on normal return
This covers common use case when you have multiple return statements in a
program, and want to print returned value for debugging, so you need to add
"print" in several places.

['Andreas Kirsch' via Dart Misc]

I have to say it's a very rare habit to catch, augment and rethrow. :(
AngularDart doesn't do that really, and neither does our code usually. I
wish it was easier or more prominent, since it would help the general
debugging user story a lot :) especially, since stacktraces don't provide
parameter information or similar in dart.

Cheers,
Andreas

Post by tatumizer-v0.2
There's one area where innovation won't hurt: adding context to
exceptions. Very often, exception is caught just to wrap it in another
exception (with more context information) and then re-throw. This is ugly.
Instead, it would be nice to have something like a function
onException((e)=>e.addContext("user $userName");
(naturally, when function(block) exits, all onException() handlers are
cleaned up automatically)
Currently, this is a major use case for "catch" Whoever doesn't want to
add catch to every function, adds a lot of logging instead. Some do both.
Program quickly becomes unreadable. Log files are getting huge and require
special tools to make any sense of them - though most of the time, you need
detailed info only if exception occurs.
P.S. Probably, this thing can be generalized to cover more use cases. E.g.
onReturn((v)=>print("returning $v from foo"); // triggered on normal return
This covers common use case when you have multiple return statements in a
program, and want to print returned value for debugging, so you need to add
"print" in several places.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[tatumizer-v0.2]

Post by 'Andreas Kirsch' via Dart Misc
I have to say it's a very rare habit to catch, augment and rethrow. :(

Depending on where you sit, the world can look completely different. I work
with production server-side code all the time (not necessarily code written
by myself). There's so much logging and catch/rethrow, you can't see the
forest for the trees (in fact, sometimes there's no forest at all, but it's
a different story).

On a system level, it's like you say - no help at all. Exceptions thrown by
system code most often don't have any context information - burden is put
on application, which adds even more bloat to already bloated application
code.

[Felipe]

Thanks guys for your detailed answers.

Lasse, I do not know if from the technical point of view (parser) is a
complication but from a more abstract and ideal perspective I liked the
idea. Maybe today analyzing the cost / benefit ratio is not viable.

Sorry for my English, it is very bad and I can hardly express myself (I'm
using google translate;-)).

Thank you

- Felipe