function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
TehNrdTehNrd 

Please fix the Debug Log!

When Apex code was first released the debug log worked wonderfully! It displayed all relevant Apex info, limits, debug statements, etc.

The new version not so much. When I am working with Apex code I could care less about workflow criteria evaluations. These do nothing but get in the way and make the debug log ridiculously long. For us this is making the debug log so long it is cutting off the top of the log and with that lots of my debug statements. This has made debugging Apex extremely tedious and very painful.

With the new version you are supposed to be able to modify the logging level but this rarely works. It's as if it has a mind of its own.

Sorry for the somewhat harsh tone but it has been very frustrating digging through literally 35,000 lines of workflow evaluations only to find that my debug statements are not there.



Message Edited by TehNrd on 07-17-2008 03:34 PM
Scott.MScott.M
This is an older comment, but I definitely agree. There needs to be better control over what gets shown in the debug log. Most of the time I'm only interested in my own debug statements, so at the very least there should be a way of specifying that I only want to see debug satements genereted by my code, or at the very least provide a way to search the log in the IDE. If I'm using the browser log I can find my statements quickly using firefox's search but no so much in the IDE. It isn't even very easy to copy and past it into a text editor so I can search, although I have done that a couple of times.
TSH53TSH53
I agree 100%. I am using the XMLDom class and because of its recursive nature, my debug log hits the *********** MAXIMUM DEBUG LOG SIZE REACHED ***********limit just trying to load up a 250 item file. My debug log is filled with unimportant 'returning from method' statements - regardless of the log level. Needless to say, it makes debugging any code that follows virtually impossible. Please correct this as soon as possible.
OCDGeekOCDGeek
Yes, there needs to be some way to specify the logging level in Apex, or better yet, make the System Log work for VisualForce pages that are displayed in sections with a standard SF page.
GoForceGoGoForceGo

Yes, indeed it is frustrating. 

 

I now use the System.ASSERT(false, 'My old debug statement') to output what I want. However downside is it stops at the first statement!

 

In past I was occasionally able to skip a lot of junk by some careful sequence of steps - set log category and log level to none and then set log category to debug and log level to debug as well...I don't think it works anymore.

 

 

jhartjhart



The big issue for me is that I can’t get the output of System.debug() statements without also getting METHOD_ENTRY/EXIT spew (as both are in the “Apex Code : DEBUG” level).

I think System.debug() statements should be placed into a separate Log Level than METHOD_ENTRY/EXIT. Perhaps METHOD_ENTRY/EXIT should be moved into the “Fine” log level.

Note the Log Level-vs-Events issue is confused, because there isn’t an Event for System.debug() statements – they show up at DEBUG, but the System Log’s “Events” list only adds METHOD_ENTRY/EXIT when you go from “INFO” to “DEBUG”.

Also, it would be useful to break METHOD_ENTRY/EXIT into USER_METHOD_ENTRY/EXIT and SYSTEM_METHOD_ENTRY/EXIT. The first only traces non-System methods; the second traces system methods. They should be placed in “FINE” and “FINER” levels, respectively.

 

So I'm asking for three things:

 

1.  An Event for System.Debug which is distinct from METHOD_ENTRY/EXIT.

 

2.  Split METHOD_ENTRY/EXIT into USER_ and SYSTEM_ flavors.

 

2.  Keep System.Debug in the 'DEBUG' leve, put USER_METHOD into "FINE", and put SYSTEM_METHOD into "FINER".

TehNrdTehNrd

I guess it wouldn't hurt to link to my blog post expanding on the issues of the current debug log:

 

http://www.tehnrd.com/if-computers-could-barf-salesforce-debug-log/

TH53TH53

One thing I have found to be very helpful to overcome many of the issues discussed in this thread is to set the log level in my system.debug call to something 'higher' in importance than just debug. For example: 

 

System.debug(Logginglevel.WARN, 'Information I want to see in the log' );

 

will cause the debug statement to output at the 'Warn' level. Then, I set the debug level for Apex code to 'Warn'. This will eliminate all the noisy debug output that you get at the debug level, while outputting the specific statements from my code.

 

Hope this helps.

jhartjhart

Good point.  I had been hoping to get "old behavior" without code change, but it's probably not possible.

 

jpumphreyjpumphrey

I tried setting the debug log filters to NONE and  I still see ALL of the debugging info (method entry, method edit, sql, etc. etc ... all of it.  Not a thing is hidden.)  Can someone please tell me what I'm missing?  This is very frustrating.

 

I tried changing the filter in "System Log" and also tried it in "Setup > Monitoring > Debug Logs." Both gave the same result ... I see all information for everything in the debug log.

 

Is there something obvious I'm missing, like a "save" button for the filter settings? 

 

I don't see a save button for the filter settings on either page so I don't even know if it's saving my changes.  It does a postback when I change a setting, but there's no change in the level of information logged.

 

I'm trying to set it up so that I can set the log level to NONE for everything except Apex code, which would be set to WARN, and then I would use LoggingLevel.WARN in my system.debug() statements.

jpumphreyjpumphrey

It seems to be sort of filtering now (maybe a flaky postback last time when I changed the filter settings?)

 

But I still see CODE_UNIT_FINISHED and CODE_UNIT_STARTED events with Apex Code set to WARN.  Is there a way to hide those events?  It's still very cluttery.