NoClassDefFoundError with the [generic] tag is called by the virtual machine from the "finished assembly" object. The exception does not have a useful stack trace, but usually does not appear on its own.
Reference Information. The class loader mechanism requires throwing exceptions when the class cannot be found in the loader. Loaders need to put off their parent loader, so if you try to load an application class, it will first ask for a boot loader that will fail and throw an exception. The application loader then performs its own search, which is likely to be successful.
This means that the virtual machine throws an exception, initializes the object and fills the stack trace ... and then throws it for each class that does not exit the bootloader class loader.
To avoid meaningless distributions, the bootloader (implemented inside the virtual machine) generates a common, pre-allocated exception object. Since the object is fully formed when the virtual machine starts, it does not have significant information about the stack trace.
In practice, you do not see them, because applications usually do not load classes directly from the boot loader. The application or system loader creates a meaningful exception for you. Even if you request a class from the boot loader directly, you should see this as the “cause” of a ClassNotFoundException .
DexClassLoader was written to use an error code instead of an exception when a class cannot be found, so you will not see this at all through this path.
If NoClassDefFoundError is the "cause" of the larger exception, you need to get the outermost exception, as this will have a meaningful stack trace. If you see them appearing on their own, something very strange happens - most likely, some bit of code tries to load classes directly and passes null instead of the classloader object (this is how you refer to the loading loader).
fadden
source share