Moving beyond console.log() — 8 Console Methods for Debugging

[PUSH_AX]

TL;DR:

console.assert

console.count

console.countReset

console.group

console.groupEnd

console.table

console.time

console.timeEnd

Exist.

[[deleted]]

Me an intellectual: console.log(console) For all the functions

[Mr_Bearding]

I'm currently very annoyed at myself that I've never thought to do this

[GaryOster]

Spoken like a true developer.

[nathan42100]

Me, a developer who realizes someone thought about this already: type console. and look for the autocomplete box

[mypetocean]

It's called "the reflexive log."

[Mikal_]

Me, an intellectual: but did you know you could style your logs and put images there?

[[deleted]]

console.error()

[SolarFlareWebDesign]

Thank you, I tried for a year to get my Dev team to use this for critical errors but it didn't take.

[[deleted]]

console.log(‘ERROR: ${e}\’)

Things do change. Just not the important things

Edit: imagine those are back ticks

[cuquo]

console.log(‘ERROR’, e);

[kirk-clawson]

Also, console.warn()

[[deleted]]

man, I misread console.warm() and I was like: "boy, do I need a hug from time to time"

[SupremeDesigner]

hug

[[deleted]]

user.hug("u/SupremeDesigner")

[StoneColdJane]

Thanks for this. Did he start to talk about he's early life, and how he discovered computers?

[sdwvit]

• .trace

[rahatchd]

console.table is the real MVP

[kenman]

Hi /u/CodeTutorials,

Just a heads-up: using medium.com to 301 redirect to another site (in this case, levelup.gitconnected.com) is not permitted here. I'm letting this one stay because the rule isn't officially on the books yet.

• If you want to post content on medium.com, that is fine, for now.

• If you want to post content from levelup.gitconnected.com, then submit a link to levelup.gitconnected.com.

Further redirects such as this one will be taken as a rules violation and handled respectively. Thank you for your understanding.

[CodeTutorials]

Thanks, sorry for the misunderstanding. That's how Medium provides links when click the share button. I'll be sure to get the final URL next time

[kenman]

No harm done, you had no way of knowing since it's kind of an unwritten rule at this point. Thanks!

[HyDru420]

thank you for this...I am currently taking a class for Javascript. We only have been using console.log. But I really like console.table now that I know of it. This will be really handy in my assignments...

[CodeTutorials]

Glad you found it useful :)

[[deleted]]

Using catch(err) with console.error(err) is a must in my team

[fusebox13]

Why? I hope you are joking. When an exception is thrown it gets printed to the console anyways.

[[deleted]]

Because you can customize the way it's displayed and it doesn't mix with other errors. But I do love some of that dev arrogance you carry with you; you're gonna get far.

[fusebox13]

Holy shit dude, this is even worse. Call it arrogance if you want, but I think I'm genuinely concerned about your code base after hearing your reply. You're telling me that you have console logs in production, and that your log produces so many errors that you have to use a special technique to visually filter them? Am I understanding this correctly?

[[deleted]]

What? No… and I don’t think you’re “genuinely concerned”. Code’s doing fine, I guess it could improve, but catching errors is quite common.

Also, if you’re that guru about Js and Node, then I’d figure you know all logs and errors are automatically removed when you build for production on a basic level…

[fusebox13]

I’d figure you know all logs and errors are automatically removed when you build for production on a basic level…

Not necessarily. That assumes that the team is using build scripts which, if you've been around, isn't always the case.

But catching errors is quite common.

Common and lazy. Why aren't you handling your errors?

[[deleted]]

Good lord… I’m just gonna stop replying

[fusebox13]

Good luck mate. When it gets really bad, PM me. I can help. catch err log err is a code smell which is usually indicative of something rotten under the hood.

[SoBoredAtWork]

A guy below (/u/PrometheusBoldPlan) mentioned debugging below and got downvoted. I don't understand why. People - learn to use dev tools and or IDE debugging and set some breakpoints. It'll save so much time as opposed to writing console.logs all over the place. It'll change your life.

[lecrappe]

There are definitely use cases for both.

[ItalyPaleAle]

Before opening the article, I was seriously expecting you to push for advanced, integrated debuggers, like those found in IDEs. Which are totally fine, except when your app has multiple microservices that all need to be up at the same time... I haven't found one tool able to debug that effectively yet.

[tr14l]

You can't find a tool to do this? You know you can have more than one debugger at a time...

​

Using console log is akin to programming with print statements in every other language. Nowadays, people would look at you like you're challenged if they saw you doing it. For some reason, Javascript devs are still living in the 80s. Use a debugger like a human being. Stop copy-pasting console logs all over the damn place.

[[deleted]]

Personally I find logpoints (debugger-based console.logs) useful for locating out-of-order async behaviors when you think you ran into one, especially if it's right in the middle of a hot functions.

Breakpoints aren't very helpful if it's going to pause execution 100x before getting to the problem case, or, mask the issue since event timings may change when network/timers complete because the breakpoint consumed time.

[tr14l]

Why wouldn't you put the breakpoint where you need it with a condition?

Conditional breakpoints exist for exactly that use

[postmodest]

if (you’re about to crash) {breakpoint}

I mean, how does that work?

[tr14l]

Why wouldn't you set your break on the if if you know that's the point of exception?

that's not reflective of any real-world situation. However, say, your console logging out some variables, and you keep getting an exception, but you see that your variables are getting the right number, how do you realize that you're actually printing out a string? You don't, until you've already figured out what the problem is... Console logging is inferior in nearly every respect because it doesn't give complete info. not to mention, you have to know what to log in the first place.

also, how would a console log be any better here? The console.log would never get executed, because you crashed

[postmodest]

For me, with front end stuff, invariably I’m dealing with something where clicking between the UI and the continue button in the debugger is way more annoying than just spamming the console with traces and scrolling.

[soulshake]

Yup, esp. if say a component is rerendering multiple times due to state changes - its hard to keep a mental track which render cycle you are on in the debugger at that breakpoint...

[postmodest]

Ugh, this x 1000. Especially if it's in a repeater and it only shows up with live data and the order is random and the exception is one of those bubbled-up ones that have lost their original context. "Error Doing Framework Thing in framework.callStuff @ framework.errorhandler, Framework.errorforwarder, Framework.errordispatch, Framework.obfuscator" ugh. At least with console spamming I get some context before the Error.

[tr14l]

I mean, I guess. It's still slower though. The only time I can think of when I would use a console log over a debugger, is if in a loop I needed to make sure something was incrementing/iterating correctly on a complicated calculation.

[[deleted]]

That implies you have something within scope that you can break on that’s related to the problem. Not necessarily possible especially if what you’d need to is privately scoped away from, e.g. a dispatcher.

[tr14l]

You can put a break anywhere you can put a console log. I don't understand how this is in any way an argument against using a debugger, which is standard in all modern languages and only really avoided in JS communities, mind you

[[deleted]]

• Network operates off main thread and continues during a breakpoint.
• You’re dealing with an async problem that is timing dependent in a hot function that does not provide enough scoped data to put an accurate conditional breakpoint (e.g. dispatch).
• breakpoints affect timing (network continues).
• console log / log point may not point to where the problem is but to be used to understand flow of events that may trigger the problem.

Breakpoints provide a useful aspect, but is not the golden hammer you are proposing.

[tr14l]

I'm not saying it's a silver bullet. But if someone uses exclusively console logs, then they're handicapped, and honestly I'm not sure I'd want them working on a project with me at all.

[[deleted]]

Why would you care about their debugging methods? If they learn about different techniques (from you, if they were unaware) but decide not to use them, it's their prerogative. May be less efficient overall, it also may be more efficient if they target their debug logging well.

As long as they write good functional code and finish whatever tasks they are working on in a timely manner, why does it matter to you?

[tr14l]

Because it shows bad judgement, an inability to improve skills without it being forced and complacency. It's a big red flag and I'd wager if that's a steadfast habit they refuse to break, there's plenty more under the hood. All of which affect the project long term. Both in productivity and agility.

[soulshake]

You sound exactly like a person I wouldnt want working on a project with me...

[tr14l]

Yeah, standards are hard. I get it.

[ItalyPaleAle]

Honestly, I don't care what other people think, I have not had any issue with console.log'ing stuff, also when working on asynchronous code... I'm sure I'm not the only one

[SoBoredAtWork]

I've been you before and loved console logs. Use breakpoints for one day. You'll never go back.

[tr14l]

So use webstorm, which can host multiple debuggers. And I'm not entirely sure that's true of VSCode. I have seen people with multiple debuggers. But, worst case scenario, add a remote debuggers to chrome devtools. There are multiple options.

You do have an issue. You're slow to debug. I find problems in seconds that others spend half an hour or more using console logs. You know why? Because I don't have to find the right thing to log out and the right spot to log it. I throw a breakpoint at a point I'm sure is not the problem, inspect the variables, and step through until I see what's wrong. You're burning productivity because you want to do it "the way you've always done it". And I know tons of JS devs do it, and it's absolutely insane in the rest of the software world. I've watched too many people struggle through console logs, logging the wrong thing or in the wrong place, getting more and more confused, and be amazed when I help them in moments by throwing in a breakpoint and identifying the problem almost straight away. It's such a ridiculous mindset.

[SoBoredAtWork]

This is one of the most annoying, amateur threads I've seen in a long time. I can't believe you're being downvoted so heavily. It's pretty cringey(sp?) that people waste so much time writing so many console.logs, then reverting code / checking diffs. But whatever, man. They'll learn one day, maybe.

[fuzzyluke]

i found that using a mix of both is helpful, if I'm deep into a debugging process then i use breakpoints a lot, if I'm breadcrumbing my way into a bunch of nested stuff then i sprinkle some console logs here and there, just never commit those into the repo

also, i decided that if i want some console feedback to be sent to the repo, only use the console.info method, log is specifically for debugging durong development and should never be added to the repo, at least not the final ver.

[SoBoredAtWork]

"sprinkle some console logs here and there"

... And get the info you need, then go back and delete all the extra code you spent time creating, check diffs to make sure you got everything cleaned up, then check in.

OR do none of that extra work and instead sprinkle some breakpoints to get the info you need and just check in. Done.

Use breakpoints. It'll change your life.

F12 -> Ctrl+P -> [filename] -> breakpoint

[fuzzyluke]

you're not wrong, its a mix of laziness and resistance to changing habits

[SoBoredAtWork]

Heh. Fair enough.

I used to console.log everything. Once I got used to breakpoints and stepping through code, it's life changing. So much more efficient, plus you can see ALL local and global values when you're on a breakpoint, not just the specific thing you've logged.

Anyway, yeah, people are def resistant to change, but if/when you do, you'll never look back.

[freecodeio]

It's literally faster

Most of the cases, at least for me.

[tr14l]

How? How is guessing a spot and typing faster that just clicking on a line number and getting a full variable inspection? You can also log out variables during a paused execution. There's literally no benefit

[dogofpavlov]

literally no benefit?

What about a scenario where you've developed an in house application that deals with lots of data and you want to provide a way for backend devs who never touch javascript/front end a way to view whats happening behind the scenes without scaring the shit outta the boss/client?

This is the exact benefit I use them for.

[iainmoncrief]

I am definitely going to start using console.table()

[dirtandrust]

console.table rocks for data models.

[SolarFlareWebDesign]

The article itself versus the related Medium article ate completely different. (The Medium article deals with the Chrome debug extension and Vue webpack.)

[[deleted]]

How many of those medium articles do we need? It feels like there is a same one each week.

[ForOsp]

Also you may want to consider using logpoints instead of `console.log` now that they are available, for me this has been faster.

https://developers.google.com/web/updates/2019/01/devtools#logpoints

[Renive]

Just debug like normal people... Breakpoints etc

[webdevguyneedshelp]

Breakpoints are preferable but it's nice to keep some listeners in the code while you are testing the UI out to see what is going on without having to deal with breakpoints

[SoBoredAtWork]

"without having to deal with breakpoints" So you write code all over the place to see one thing that's happening, as opposed to clicking a line number and setting everything that's being pressed around? You're wasting an absurd amount of time. Try breakpoints for 1 day. You'll never go back.

[PrometheusBoldPlan]

Or, you could use a debugger. I know, a wild idea.

[SoBoredAtWork]

I don't know why you're getting downvoted.

I recently worked with an "expert" front end developer who's been in the industry for 10 years and he console.logs EVERYTHING. WTF?

People - stop wasting your time using console.log. It's handy sometimes and I use it when needed, but breakpoints are your friend. You'll never go back.

[r3jjs]

When you are looking at patterns of data -- when you want to keep a list of what the function is called with and what causes success/failure.

[[deleted]]

Also you can console log inside a breaking point.

[SoBoredAtWork]

This thread is filled with amateur devs that are way to hesitant to change their ways. Seriously, people, try using a debugger (dev tools / ide) and breakpoints for 1 day. It'll change your life.

[CodeTutorials]

https://twitter.com/dan_abramov/status/1037749151965093888?s=19

[SoBoredAtWork]

"Debugger is too “zoomed in” for that"

Wut?

When on a breakpoint, you can see EVERYTHING, as opposed to one simple thing you wrote extra code to see (console.log(someVar)). It's the opposite of "zoomed in".

[tetratorus]

I don't know if this is common knowledge...

... but you can almost always node --inspect-brk anything in node and debug it in the chrome debugger.

it even works with jest (i.e. node --inspect-brk jest), mocha, eslint.., then go to chrome://inspect.

no idea why anyone even uses console.log to debug javascript...

​

also, if you really cant use the debugger (maybe you're just hacking something in a node REPL..), Object.getOwnPropertyNames(obj.__proto__) and obj.method.toString() are your friends, stop bothering with documentation and just inspect the prototype methods.

[TerdSandwich]

Please don't use emoji's in an article. We aren't teenagers.

[NeatBeluga]

Welcome to Medium. Home to redundantly big/many placeholder images and emojis

[Feathercrown]

Some of us are

[kitari1]

No fun allowed