I very rarely, if ever, do step debugging or conditional watchpoints anymore. I used to do them, but somehow I've found this process of debugging is actually rather time consuming.
One of my primary methods for debugging is writing more unit tests. Anytime I have an idea, or suspicion, about the error I write a test that tries to emulate it. One great advantage to this approach is that my debugging time isn't lost, it's all encoded in unit tests that will remain with the project.
Of course, that doesn't always work. Catching thrown exceptions in a debugger is something I do often to figure out where an error is happening. I don't step at that point, I just inspect the code. This approach works well if you pepper your code with lots of runtime checks -- anything that even remotely smells funny should raise an alarm of some kind.
A Java Evangelist, looking to improve the humankind and the way we create software. Like to speak with people, and learn new things about software, fitness, motorcycles, life, astronomy.
let's talk.
The debugging process is from time to time just a time-consuming activity with no results, but there are some cases as you mentioned that you need to figure out a runtime exception that may occur due to a bad development or a wrong architecture.
This is just an additional tool in the problem-solving process.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I very rarely, if ever, do step debugging or conditional watchpoints anymore. I used to do them, but somehow I've found this process of debugging is actually rather time consuming.
One of my primary methods for debugging is writing more unit tests. Anytime I have an idea, or suspicion, about the error I write a test that tries to emulate it. One great advantage to this approach is that my debugging time isn't lost, it's all encoded in unit tests that will remain with the project.
Of course, that doesn't always work. Catching thrown exceptions in a debugger is something I do often to figure out where an error is happening. I don't step at that point, I just inspect the code. This approach works well if you pepper your code with lots of runtime checks -- anything that even remotely smells funny should raise an alarm of some kind.
Thanks for your feedback Eda.
The debugging process is from time to time just a time-consuming activity with no results, but there are some cases as you mentioned that you need to figure out a runtime exception that may occur due to a bad development or a wrong architecture.
This is just an additional tool in the problem-solving process.