Why are you unwilling to use question marks to mark your questions?

But everything to do with people's willingness and ability to volunteer their
precious time to help you with it.

If you report the situation inaccurately, advice given will be inaccurate and
likely useless.

Accurate and rigorous information is needed to be of any assistance.  Are you
sure you don't want to provide that?

There is no such exception in the standard Java API.  Did you mean
NullPointerException?

If so, you should say so.  Inaccurate information leads to inaccurate and
useless diagnoses.

There may not be an error.  If an Exception or Error or any other Throwable
were thrown, you'd have gotten a message to that effect already.

Did you?

These are very different categories of problems, reported by different types
of Throwable in Java.

Division by zero doesn't even necessarily throw an exception.  It could just
yield a valid value.

You need a reliable way to detect a hang and break out of it for that to
happen.  Infinite loops and thread deadlock are examples of situations that
will not spin out any throwables.

A good logging package, like the inbuilt java.util.logging package or the
open-source log4j library, can report the type of information you seek.

If you log at FINE (java.util.logging) or DEBUG (log4j) level, or more
detailed, you can spin off log information at various points in your algorithm
that can help diagnose even such problems as infinite loops and thread deadlock.

try-catch probably will not reveal the source of your problem.

Use try-catch whenever the code explicitly has a path that might throw an
exception.  In the catch block be sure to use your logging library to report
the exception.

In other situations where try-catch will not help, logging still will.

<http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html>
<http://logging.apache.org/log4j/1.2/index.html>

On Jan 13, 9:56 pm, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:

...

If people had continued to be so 'nice' to me
as not to point out the basic realities, I might
still be a 'newbie'.

--
Andrew T.

Clearly there is something wrong with the code.

...

In this situation I would avoid investing a lot of time and effort in
changing the environment. *Anything* you do to debug this carries the
risk of reducing the failure frequency without removing the underlying
bug. A 1-in-10 failure is far easier to debug than a 1-in-100 failure.

Instead go with desk-checking combined with inserting System.err.println
statements in potentially relevant places. The sort of thing you should
be looking for is a situation in which you have a loop in the set of
resources that can be held by a thread while waiting for another resource.

For example, suppose you have a pair of objects A and B that are both
used for wait-notify, and you have two threads such that:

Thread 1 owns the lock associated with A, and is waiting for B.

Thread 2 owns the lock associated with B, and is waiting for A.

Obviously, neither thread can make progress.

In general, you should be able to write an ordered list of lockable
resources such that a thread waiting for a resource never holds anything
that appears later in the list.

Also, check that all graphics component manipulation is in the event
dispatch thread.

See http://home.earthlink.net/~patricia_shanahan/debug/ for some more
ideas on debug.

Patricia