DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Why We Still Struggle With Manual Test Execution in 2025
  • Copy SQL Execution Plan from One Database to Another in Oracle 19c
  • Level Up Your Code With Formal Methods
  • Ulyp: Recording Java Execution Flow for Faster Debugging

Trending

  • Operational Principles, Architecture, Benefits, and Limitations of Artificial Intelligence Large Language Models
  • Unit Testing Large Codebases: Principles, Practices, and C++ Examples
  • Next Evolution in Integration: Architecting With Intent Using Model Context Protocol
  • How to Ensure Cross-Time Zone Data Integrity and Consistency in Global Data Pipelines

Logging or Debugging

By 
Peter Verhas user avatar
Peter Verhas
DZone Core CORE ·
Mar. 11, 14 · Interview
Likes (0)
Comment
Save
Tweet
Share
4.7K Views

Join the DZone community and get the full member experience.

Join For Free

debugging is lame. you should debug log.

if your code is structured you do not need debug logging.

these are two opinions from the two ends of the line. i am, as usually, standing in the middle, and i will tell you why.

first of all, there is no principal difference between debugging versus logging. they are just two different implementations of the same thing: observation of your execution engine state in time dimension.

issue with debugging

when you debug you step your program forward in time and at any point the execution stops you can examine the value of any variable. the shortage is that you can not step back in time. at some points you realize that you would just like to see what the value of a certain variable was just before some method was called, some object was created or whatsoever happened in the system. what you actually do in such a situation is to restart the code and hoping it behaves deterministic try to catch the execution at the earlier stage that you are interested in. and this is another shortage of debugging. you can not effectively debug a code that does not behave deterministic. and trust me: most bugs behave non deterministic.
debug versus logging

issue with logging

with logs the major issue is different. it is not the time but rather the breadth of states, variables that you can look at is the problem. you insert log statements into your code dumping the values of variables into a log file at a certain point of execution. when you examine the log file you can scroll back and forth. however if you did not print out the value of a certain variable at a certain execution point, there is no way to get it from the log file. the solution is the same as with debugging: execute the code again, this time extended with the new log statements. if, however, you have enough information in your log files, then you will just get enough information to track down a bug even if that is not deterministic. only ‘if you have’ …

solution: logging all the states all the times?

the ideal solution would be to dump all variables into a possibly binary log file at each state of the execution and examine the content of the file afterwards. the examination would essentially look like a debugger, except that the change of the variables comes from the recorded log file instead of from on the fly calculation. it would be like a playback of a recorded execution and as such you could replay it several times. i do not know if there is any tool like that for the jvm.

you just can not define what is “each state” effectively in a multi thread execution environment like the jvm is. this is one of the issues. the other thing is that if you’d start dumping the jvm memory after each command (forgetting the issues of multi-thread) it would require enormous amount of bandwidth and disk space.

dreaming about the ideal solution not deliverable is sort of no use. what is the solution that can practically be executed?

practical approach

you can debug when it is appropriate. full stop. you just did that so far, keep doing that. i tend to use log statements even when i debug some code and if the environment allows it i do it on the fly. when i find the root cause of the issue i am hunting i review the log statements and i delete them. they did the job while debugging, they are not needed anymore. at least that was my practice unit i found myself writing log statements that i have already created before. why? because fixing one bug does not mean that i have fixed all of them. there is nothing like all bugs fixed. but the log items littered the log file and that just increased the work to find the needed information hunting the next bug. in other words the log file is full of noise and that is why i deleted these items the first place. but for the same reason i could also delete the unit tests that already pass. it would save a lot of time during compilation, wouldn’t it? we do not do that.

summary in one sentence? log and debug the way it fits you and the issue you are hunting.

Execution (computing)

Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Why We Still Struggle With Manual Test Execution in 2025
  • Copy SQL Execution Plan from One Database to Another in Oracle 19c
  • Level Up Your Code With Formal Methods
  • Ulyp: Recording Java Execution Flow for Faster Debugging

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: