Removed Priority-Medium label.
Added Priority-Unassigned label.

For what it's worth, I really dislike calling this "debugger". Maybe some kind of breakpoint() top-level function in some library would be nicer? If you really want to we could make it a getter to avoid the parentheses.

Removed c2 label.
Added C2 label.

This is more a library question as Kasper points out. Where should this debugger breakpoint call live?

cc @mhausner.
cc @kasperl.
Removed the owner.
Removed Type-Defect, Area-VM labels.
Added Type-Enhancement, Area-Library labels.

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

Hmm, how about a mode in which failed assertions drop you into the debugger? Then you can trigger a breakpoint using "assert(false)", and conditional breakpoints are easy.

(In this mode you'd also want to be able to continue after a failed assertion.)

A debug library would be the obvious choice.
We are considering it for other reasons as well, but haven't gotten around to looking at it seriously yet.

cc @floitschG.

Unless there are objections I'm fine with adding dart:debug with this method. I'm confident that we will have more utility classes/methods that fit into the dart:debug library.
I would also make dart:debug "unstable" (at least for now). It is supposed to be something for debugging and should not exist in production code.
I'm proposing breakIntoDebugger() for the actual method name. It is long, though. If there are better suggestions please speak up.
(I don't like "breakpoint()" because it has a noun-name. It would need to be a getter, which would be another alternative.).

Some candidates: showDebugger, stopInDebugger, debug.stop()

This comment was originally written by @mhausner

breakIntoDebugger() is definitely too long, especially so for a language that tries to be terse.

How about halt(); or halt;

another candidate: debugBreak()

If the function is in a separate library (like dart:debug) then "break()" might actually be enough.

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

But "break" is a reserved word. Perhaps "breakpoint()".

Right. forgot about that... :(
breakpoint would need to be a getter then.

We should maybe also think about names that contain the expression to be executed.
For example: foo(bar(), debug(toto()))

In this case I would want bar to have executed, but not the call to toto.

debug(); would then just be a shorthand for debug(null).

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

What would that mean? The JavaScript debugger statement doesn't take any parameters or return anything. Also, it's a statement so it would tricky to execute while evaluating an expression.

We are in control of what dart2js emits, so no problems there.
For the DartVM we don't need to follow the example of JavaScript, and switch from statement to expression.

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

When debugging it helps to keep things as simple as possible, to make it less likely that the bug goes away when you try to debug a problem. So I'd prefer a way to simply emit a JavaScript "debugger" statement without any other changes to the AST that might cause the dart2js compiler to optimize the code differently. (There is always some change but we should try to minimize it.) This sort of low-level control should be left in the hands of the programmer as much as possible.

We don't design language/library features under the assumption that our tools are broken. Sometimes we take some inherent limitations (for dart2js the JavaScript language) into account, but otherwise we should just fix our tools.

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

That's assuming the JavaScript "debugger" statement is somehow broken, and I'm not seeing that. Does anyone care about setting a breakpoint in an expression? It seems like we shouldn't add complexity without a compelling reason.

Also, fixing all the tools isn't actually practical. Since we're talking about debugging, the runtime environment includes the debuggers for Firefox, IE, and the iPhone. We need to play well with those.

This comment was originally written by @mhausner

cc @peter-ahe-google.

https://codereview.chromium.org/204483002/

I agree with Florian: debugging expressions is important. I've never heard a user complain that they could set precise breakpoints. In fact, expression-level breakpoints is a feature in both Eclipse and NetBeans, and was considered a major deficiency in NetBeans until we implemented it.

As far as I can tell, Florian's solution wouldn't change Brian's workflow. Dart2js will inline the method and simply emit a debugger statement.

Set owner to @peter-ahe-google.
Added Started label.

Can this be closed?

Yes, this functionality has been added in the dart:developer library (https://api.dartlang.org/stable/1.20.1/dart-developer/dart-developer-library.html)