How to capture exceptions at physics thread?

Troubleshooting physics
9

For anyone interested in stopping the application on any SEVERE log entry from any thread, you can add a handler basically like this:

class ExitHandler extends Handler{
	@Override
	public void publish(LogRecord record) {
		if(record.getLevel().equals(Level.SEVERE)){
			if(record.getThrown()!=null){
				System.exit(1);
			}
		}
	}

to all (available to the moment) loggers from this list:

LogManager.getLogManager().getLoggerNames()

and force some logger to exist beforehand with:

Logger.getLogger(fullClassNameGoHere);

@pspeed I didnt go on EventBus yet (there seems to have another also), but I believe the above code will have the same final result?

The only thing missing is that, for the Eclipse IDE to “auto-breakpoint” on the exception point seems simply impossible as it was trapped (may be it can, just didnt find how yet). So the workaround is still here to at least suspend on the message being logged, you can “drop to frame” but as the physics thread already provided an “exceptional” execution of the code, that cant be rolled-back, so just add the breakpoint where the real exception happened and wait next physics thread loop or run the application again.

Thoughts about the Logging API

I would like to add that, the logging API push me away from the beginning, the limitation of “log level” was a bad thing for me, I didnt know about categories tho. I wanted to see things considered low and high log level at the same time. And at that time I found it to be unnecessarily confusing (now it is more clear tho).

But worst, why I have to go thru a bloated log file if many of the warnings and errors are so similar (if not identical). So I decided to do my own logging in memory, I limited it by 100 log entries per kind (and I have added many kinds even TODO hehe), I can review them and dump more or less information, but most importantly, they are unique as much as possible, no repetitions! only the last entry have its values stored. I think the logging API should be like that by default. (may be it can do that, I just cant stand learning it right now :slight_smile: , my project goals are priority, but thx on the tip. May be if I release some library, it will use that API, may be not :slight_smile: ).

Also I believe I could adapt it to conform with the logging API, but I felt I would spend too much time in something I implemented an alternative in a few hours. Later on I can even adapt it to that API, so end users can use the global log options to control the way my application log will work,