[Solved] Debugging AssetLoadExceptions could be made easier

I wasn’t really sure how to categorize this, so apologies if this is the wrong category.

Recently (after working through an issue from a different thread), I came across a problem attempting to load a font asset. I made sure I was loading the correct file, but there was some error when loading the associated image data. At the time, all it said was something to the effect of ‘AssetLoadException: An error occurred while attempting to load the asset’ (this may be minorly paraphrased, as I hadn’t thought to take screenshots at the time).

I puzzled over how to interpret this vague error, which led me to dive into the Javadoc. It turns out that AssetLoadExceptions have a reference to a ‘cause’ - a separate exception that was, well, the cause of the error. In order to read this ‘cause’, though, I had to wrap my existing code in a try:catch block, catch the AssetLoadException, and print the stack trace of the cause. This gave much more useful information that enabled me to fix the problem immediately. (The actual error that occurred was that my image data was formatted incorrectly [it used indexed color instead of full color, which wasn’t supported], but that’s beside the point.)

If I could make a suggestion/feature request, I’d request that AssetLoadExceptions (and other exceptions that have ‘Cause’ fields) display the message from their cause (if one exists) in addition to the existing stack trace. This would have made the debugging process easier in this case, and likely in others as well.

Are you talking about in the SDK?

AssetLoadException passes its cause up the chain to Java’s base class which means in all normal places to see a stack trace (console output, logging, etc.) it will include the cause.

So this may be more related to how you are running the application. And if it’s SDK specific then we may want to move this topic over there.

(I don’t use the SDK so I’ve never seen this personally as all my asset exception stack traces include the cause.)

Edit: it looks like we do not have an SDK-specific dev topic but if it is SDK related then maybe we can edit the post title to reflect that.

It includes the cause, but not the string associated with the cause - the thing that actually explains what the error was, rather than just what the error was itself the kind of exception that was passed (Edit: realized that was utter nonsense, sorry). Like, I could tell it was an error with the TGA loader, but not that the error was that the TGA format was invalid for JME3.

Unless I just don’t know how to read error logs, in which case :man_shrugging:

Unless Java’s logging is even more of a piece of crap than I already think it is (hard at this point), it should be printing the full stack trace of each cause… which includes the message in the exception.

log4j certainly will. Even regular old printStackTrace() will.

Sample code to illustrate:

try {
    try {
        throw new RuntimeException("inner cooler message");
    } catch( Throwable t ) {
        throw new AssetLoadException("outer", t);
} catch( Throwable t ) {

Produces something like:

com.jme3.asset.AssetLoadException: outer
    ...long stack trace...
Caused by: java.lang.RuntimeException: inner cooler message
    ...shorter stack trace...
        ... 27 more

Maybe @clericbob you should give a concrete example of the complete log stack you get and then show us how would you like it instead? Seems that you have a case there where you can extract this example.

I’m not certain if OP is asking about the console log or the JME Swing error dialog window. Afaik the latter will just show the error name and the message, not the cause.

Yeah, in that case you need the console output (or logging configured to also go to a file) to see the full stack trace.

Okay yeah it turns out I just can’t read apparently, or otherwise I just somehow missed that the cause was listed in the stack trace. If I have anything to justify myself, it’s that I almost never look at the bottom of a stack trace because there’s never any relevant information there, but that’s where the cause information for an error like this gets placed apparently.

TL;DR I’m blind, y’all can close this.