简体   繁体   中英

Why is Debug.Print discouraged?

I have seen a few different answers on SO that discourage the use of Debug.Print while debugging applications .. but nobody ever goes into exactly why its bad. I googled it, of course, but the results didn't turn up anything usable.

Can anyone clarify why Debug.Print is so bad?

It's noisy - all the debug statements end up mixed together.

It's easily missed - there's a ton of other output in that stream as well, easy to miss stuff.

It doesn't give enough context - there's no stack trace, no current variable values if you forget to include them, etc...

It only goes one place (the debug output) so it's hard to send to a disk file, database, etc.

Basically, it's no good for logging since you can't control where it goes, and it's no good for debugging because the debugger does everything better.

There's really nothing wrong with it, there are just better options.

If you're going to be outputting data you may as well log it. If you do that you actually get something back from the investment.

Additionally printing out variable info is less effective than setting a break point and inspecting those values in the debugger. Particularly in VS where these tools are excellent.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM