Program is silently ending computations after a presumed error

Troubleshooting SDK
1

Is there a setting in the JME that I’m not seeing that is able to silence my errors in my program? There are literally NO catch statements in any of my classes yet it’s obvious when it runs into a bug because whatever linear tasks the program has running will drop. I’m so tired of having to tread around this so I’m asking you all for help.

So to sum it up:
Program runs into presumed error
Nothing prints in console
Subsequent tasks (such as println() statements) are ignored

It happens with things like for loops going into arrays (which makes me think I’m hitting an ArrayIndexOutOfBoundsException but I’m not 100% sure). When I remove those loops, subsequent tasks function fine.

2

So I figured out that it must have something to do with my Runnable because I attempted to load a model that I did not have in two areas of my program: one in the main method, which returned an error, and another within the Runnable which did not return an error (the program continued to run, just without anything from the Runnable).

3

How are you running the Runnable? It very much matters for how the exception is handled and we can’t see it.

4
@pspeed said: How are you running the Runnable? It very much matters for how the exception is handled and we can't see it.

[java]
itemsQue.add(location);

threadpool.submit(new Runnable()
{
@Override
public void run()
{
Node chunkNode = getWorldItem(location);

	if (chunkNode != null)
	{
		newItems.add(chunkNode);
		
		app.enqueue(new Callable<Boolean>()
		{
			public Boolean call()
			{
				itemsQue.remove(location);
				
				return true;
			}
		});
	}
}

});
[/java]

5

When you use submit() it wraps your runnable in a Future and otherwise swallows all exceptions. With submit you are supposed to use the returned Future object to check for completion and exceptions.

Presuming your threedPool is a ThreadPoolExecutor then you should probably call execute() instead. Then at least you will get the default exception handling which should be to dump the stack trace to the console.

6
@pspeed said: When you use submit() it wraps your runnable in a Future and otherwise swallows all exceptions. With submit you are supposed to use the returned Future object to check for completion and exceptions.

Presuming your threedPool is a ThreadPoolExecutor then you should probably call execute() instead. Then at least you will get the default exception handling which should be to dump the stack trace to the console.

I’ve replaced my one occurrence of submit() with execute() and I am still not receiving any exceptions. Are you able to demonstrate where I should place my execute() if I’m doing it wrong?

7

Try :
[java]
public Boolean call() throws Exception
[/java]

8
@jonesadev said: Try : [java] public Boolean call() throws Exception [/java]

Unfortunately that does not seem to work. I should be seeing an exception at this line:

[java]
Node newChunk = getWorldItem(location);
[/java]

9

No, that line will never throw an exception. Maybe something inside of it would… is that what you meant?

It would be easy to make a test case to prove us wrong.

[java]
threadpool.execute( new Runnable() {
public void run() {
throw new RuntimeException(“Did this get swallowed?”);
}
});
[/java]

Note: this presumes you are running in an environment where stack traces are normally seen.

10
@pspeed said: No, that line will never throw an exception. Maybe something inside of it would... is that what you meant?

It would be easy to make a test case to prove us wrong.

[java]
threadpool.execute( new Runnable() {
public void run() {
throw new RuntimeException(“Did this get swallowed?”);
}
});
[/java]

Note: this presumes you are running in an environment where stack traces are normally seen.

Yes, that’s what I meant.

Nope, the console never displays the exception.

11

For debugging I’ve used a “try{}catch” inside my runnable to catch any exceptions and print them from the catch code.
That allowed my to find the exception and its cause, once the issue was fixed I removed the try-catch, not that there’d be an issue leaving it in.

–Radan.

12
@mjbmitch said: Yes, that's what I meant.

Nope, the console never displays the exception.

So, if you run this code:
[java]
ExecutorService threadPool = Executors.newCachedThreadPool();
System.out.println(“Executing a test:”);
threadPool.execute(new Runnable() {
public void run() {
throw new RuntimeException(“Is this swallowed?”);
}
});
Thread.sleep(10000);
[/java]

…you don’t see anything printed to the console? Do you at least see the “Executing a test”?

If you don’t see the exception (and do see the println) then either some other piece of code (not JME) has overridden the default thread handler or your Java is very broken.

If you don’t even see the println then we’ve all been wasting our time because you are not seeing any printed output so of course you won’t see exceptions either.

13

I’m not sure if this changes much, but my threadpool is initialized outside of the class constructor with this line:

[java]
private final ScheduledThreadPoolExecutor threadpool = new ScheduledThreadPoolExecutor(Runtime.getRuntime().availableProcessors());
[/java]

@pspeed said: So, if you run this code: [java] ExecutorService threadPool = Executors.newCachedThreadPool(); System.out.println("Executing a test:"); threadPool.execute(new Runnable() { public void run() { throw new RuntimeException("Is this swallowed?"); } }); Thread.sleep(10000); [/java]

…you don’t see anything printed to the console? Do you at least see the “Executing a test”?

If you don’t see the exception (and do see the println) then either some other piece of code (not JME) has overridden the default thread handler or your Java is very broken.

If you don’t even see the println then we’ve all been wasting our time because you are not seeing any printed output so of course you won’t see exceptions either.

I do see the println() statement but do not see the exception that’s supposed to be printed (this is with my current threadpool setup – it’s actually a ScheduledThreadPoolExecutor).

14
@mjbmitch said: - it's actually a ScheduledThreadPoolExecutor).

Which uses a future internally even for execute: (ScheduledThreadPoolExecutor (Java Platform SE 7 )) and …

@pspeed said: When you use submit() it wraps your runnable in a Future and otherwise swallows all exceptions.

so that might be it :wink:

15
@mjbmitch said: I'm not sure if this changes much, but my threadpool is initialized outside of the class constructor with this line:

[java]
private final ScheduledThreadPoolExecutor threadpool = new ScheduledThreadPoolExecutor(Runtime.getRuntime().availableProcessors());
[/java]

I do see the println() statement but do not see the exception that’s supposed to be printed (this is with my current threadpool setup – it’s actually a ScheduledThreadPoolExecutor).

Yep… too bad we had to wait until now to find this out. I should have asked explicitly instead of strongly hinting.

So, you have two choices:

  1. don’t use scheduled thread pool executor… but I assume this is not an option since you probably want the scheduling.

  2. do your own exception handling inside the run() method. Generally since scheduled thread pool executors don’t deal with constantly submitted random workers and likely deal with only 1 or a few specific worker tasks, then this is not really a problem.

Edit: those are the easiest options, anyway.

16

Actually, why are you using a scheduled thread pool if you aren’t actually scheduling the tasks?

1 Like