ArrayList in Eclipse

[Dirk Bruere at NeoPax]

I have an arraylist that I load with stuff when the app starts.
Is there any way I can check its contents in debug mode in an ongoing basis?

 

[Lew]

I have an arraylist [sic] that I load with stuff when the app starts.
Is there any way I can check its contents in debug mode in an ongoing basis?

Create a "watch" on the variable that points to it.

I doubt very much that you created an 'arraylist'. If you did, you need to
change your class names to match the coding conventions.

 

[markspace]

I have an arraylist that I load with stuff when the app starts.
Is there any way I can check its contents in debug mode in an ongoing
basis?

If it's really an issue you might consider put a log statement with a
log level of FINEST on that variable. If it's an issue now it's likely
to be an issue at some point in the future.

You strike me as new to Java, if not new to programming in general.
This statement from the log4j page is interesting:
"Inserting log statements into your code is a low-tech method for
debugging it. It may also be the only way because debuggers are not
always available or applicable. This is often the case for distributed
applications.

"On the other hand, some people argue that log statements pollute source
code and decrease legibility. (We believe that the contrary is true)."
<

I've also found that well placed log statements are a faster way of
debugging than stepping through code in a debugger. And debuggers can't
be used when timing is a source of error.

<http://logging.apache.org/log4j/1.2/>

 

[Nasser M. Abbasi]

I've also found that well placed log statements are a faster way of
debugging than stepping through code in a debugger. And debuggers can't
be used when timing is a source of error.

<http://logging.apache.org/log4j/1.2/>

It depends on the situation. In some cases, log debugging is
much more productive. Sometimes, one want to set a breakpoint
somewhere and examine data in a way not easily done by logging.

One problem with log debugging is how to turn it on/off on
selected area of the applications. If one wants logging generated
from one function and not another, then one ends up using more
flag and switches. Also there can be a need to change the
level of debugging (verbose, summary, etc...)

But I think a well designed logging facility can achieve
most of this, but I think this needs to be designed and
developed as part of the whole application. For large
applications, a good logging facility is essential.

I think some programmers add logging after the application is
deveopled, instead of designing it as part of the application
itself.

--Nasser

 

[Arved Sandstrom]

It depends on the situation. In some cases, log debugging is
much more productive. Sometimes, one want to set a breakpoint
somewhere and examine data in a way not easily done by logging.

One problem with log debugging is how to turn it on/off on
selected area of the applications. If one wants logging generated
from one function and not another, then one ends up using more
flag and switches. Also there can be a need to change the
level of debugging (verbose, summary, etc...)

But I think a well designed logging facility can achieve
most of this, but I think this needs to be designed and
developed as part of the whole application. For large
applications, a good logging facility is essential.

I think some programmers add logging after the application is
deveopled, instead of designing it as part of the application
itself.
--Nasser

I agree generally. A lot of logging does get added after the fact by
maintenance programmers doing defect fixes, who, being the ones that
actually do most of the defect fixing (seeing as how the production
users are doing most of the real testing), see the practical value of
logging.

In the *real* world, for the majority of production deployments, there
are no (or inadequate) unit and functional test suites. Also in the real
world, for the majority of production deployments, the problem reporting
from the field is anecdotal - it can only report the observations of
(typically) one user or a small group of users, but it doesn't report
the snapshot state of the entire application; identifying a problem
reproducing scenario is often difficult or not possible.

And also in the real world, the problem often manifests because of the
interaction of hundreds of users - the typical lack of unit/functional
testing also means that there is no possible useful load testing
available. You can't reproduce the problem for a debugging session
because it's a probabilistic event.

Good logging goes a long way towards addressing these problems.

Debugging is OK, and sometimes the best way even, if the debugging
developer isn't all that familiar with the code, and the problem is
highly reproducible. Otherwise it's not often the best way (or even
worth bothering with). My opinion.

Adding logging after the fact will work OK if the application itself is
well written. You can then carefully control how much logging happens
for usefully selectable parts of the app. As you've suggested, for a
badly written app this can be a challenge. And almost by definition, if
an app was written not to have logging, it probably is an app with issues.

A couple of real-world notes:

1. In contrast to the oft-repeated mantra that you should not turn
logging up to detailed, in production, until s**t happens, think again -
for a really hurting app (which is many or most of them) you may as well
take the minor performance hit and crank those logs right up. You'll
need the logs anyway.

2. For a large impenetrable application with no logging, you sometimes
get the most bang for the buck with "println" logging introduced with
aspects.

AHS

 

[Dirk Bruere at NeoPax]

If it's really an issue you might consider put a log statement with a
log level of FINEST on that variable. If it's an issue now it's likely
to be an issue at some point in the future.

You strike me as new to Java, if not new to programming in general.

..asm, C++, C#

 

[Eric Sosman]

.asm, C++, C#

Okay, so no programming experience.

;-)

 

[markspace]

Okay, so no programming experience. ;-)

That gave me a chuckle. I was going to reply how much longer my list
would be, but I decided it might look quarrelsome or snippy.

But I'm a little surprised Dirk didn't know about watchpoints. All
modern debuggers have them. Even not so modern debuggers have them
(db). I suppose he didn't think Eclipse would have something by the
same name.

The lesson I think is to Google for what you know first. "Eclipse
watchpoint" returns a ton of useful looking hits. It takes less time
than waiting on usenet to answer your question. Plus, Google rarely
makes snippy commentary on your requests. ;-)

 

[Dirk Bruere at NeoPax]

That gave me a chuckle. I was going to reply how much longer my list
would be, but I decided it might look quarrelsome or snippy.

But I'm a little surprised Dirk didn't know about watchpoints. All
modern debuggers have them. Even not so modern debuggers have them (db).
I suppose he didn't think Eclipse would have something by the same name.

The lesson I think is to Google for what you know first. "Eclipse
watchpoint" returns a ton of useful looking hits. It takes less time
than waiting on usenet to answer your question. Plus, Google rarely
makes snippy commentary on your requests. ;-)

It was easier in Netbeans.
I hate having to learn new IDEs