[fideloper]

It's a simple way to do it - I think usually a good stack trace for errors or a debugging environment which allows break points might cover most of this functionality and give some other information a simple console.log would not give you.

That being said, I like the idea of tracing information the developer specifically thinks is relevant as its called and having it logged out.

[enoex1]

For errors I'll always log the full stack trace (in JS, at least). This helps a ton for when errors occur, but I find that often times it's not explicit errors that are a problem (e.g., making sure the right message is sent and received from a queue system). Of course, setting breakpoints can give more information, but it's not always obvious where a breakpoint needs to be set (e.g., when a new person comes on the team) - for me, logging points me to where I need to set breakpoints, speeding up my development time.