I have a GroovyShell instance parsing code inside my Tomcat/Java application. The parsing is very slow, about 1 second for 100 lines. When profiling the application I noticed the parsing throws lots of java.lang.ClassNotFoundException exceptions. I guess something's swallowing them since I don't see them anywhere in the log. Since the script uses a lot of the main application's classes I'm assuming that that's what's slowing down the application.
Is there a way for me to catch those exceptions and get their data? What could be causing them? Is it possible that I'm using the wrong class loader?
Is there a way for me to catch those exceptions and get their data?
It is difficult to answer that without more information that indicates what is causing them. It may be that you are referencing classes that are not available in the appropriate class loader. It might be that the exceptions are expected. More info would be needed to answer that.
What could be causing them?
Code referencing classes that aren't available to be loaded is one thing that can cause them.
Is it possible that I'm using the wrong class loader?
It is. Without seeing your code and knowing more about the which classes cannot be found, it is difficult to say for sure that is the issue though.
Related
Which is more suitable out of these two exception object (e) or e.getMessage() for log.info() and log.error() or log.debug().
What should be followed/rule of thumb for different logging levels.
It really depends on the reason of the exception being thrown. I would add here WARN level consideration as well. If this is an unexpected error that should not happen, meaning that this is something wrong with codebase you should definitely log the whole exception object, especially to get the stacktrace that allow developer to find and potentially fix issue faster. Therefore such situation should be logger on ERROR level if this is something wrong with the system, or WARN if this is something wrong with client's data.
INFO level should really not contain exception details, it should keep information easy to read by non-developers(for example testers) and describe the most important parts of the data processing flow.
I think it is up to you to put exception in DEBUG level but I would still recommend not to do it just to keep things clearer OR use e.getMessage() to describe it.
P.S. In general, I would redirect this question to this page since it is a general SE question but since you asked about using particular Java feature I wanted to keep things in the right place.
Don't try to create a fixed rule about including or not including the stacktrace depending on the log level. Instead, when creating a log entry, ask yourself:
Who will read that entry? A user, a system administrator, or a developer?
What information will be useful to that reader for understanding the situation? It's better to add too much information than to omit important parts.
If the entry is to be read by a developer, is the text enough or should I include the stacktrace? Non-developers typically get confused when seeing a stacktrace, but developers very much appreciate it.
This will greatly improve the quality of your logging.
As a very rough rule of thumb, include the stacktrace whenever you log an exception. An exception means that something went wrong, which might involve analysis by a developer, who will be very unhappy if the log entry only reads "NullPointerException" without a hint where it came from.
Of the typical log levels, INFO might be the one not addressing developers (thus not asking for a stacktrace), but generally you don't want to use INFO for exceptions.
I'm modifying a java program to search through a specific folder and load plug-ins at runtime. The plugin code is working fine. I have created an UncaughtExceptionHandler to catch problems with plugins that weren't coded properly, and for the most part that works. Except for one issue (one so far, anyway):
The plugins need to have a class that implements a specific interface, so that the main program recognises them as plugins. If the developer misses one of the abstract methods, an AbstractMethodError gets thrown. It goes through my ExceptionHandler and I'm able to put up a message to the user indicating that there's a problem with the plugin. After that, though, the program just hangs. What I want is the program to continue going so that I can skip the rest of the plugin stuff, remove it from the plugin list, and let the user run the main program without it. I put a try/catch block directly around the call to the missing method, but the catch doesn't get executed. It just goes to the ExceptionHandler and then... I don't know where it goes.
This is my first attempt at exception handling so I'm sure I'm just missing something obvious. Any help would be greatly appreciated. Thanks so much.
The problem with exceptions that sub-class from the Error class is that most of them are not recoverable (in your case it's AbstractMethodError). As per the Error class java-doc:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
I.e. it's not guaranteed that the app is recoverable after an Error is thrown. Depending on how you load/execute that plugin there might be some workarounds. First of all, you could check the loaded plugin class via reflection (some examples) if there is an implementation of the needed methods before actually trying the exectuion - so you could catch/throw an Exception rather than get the Error and hang later.
If it's not an option, you could investigate further on what is actually hanging after getting that error by analyzing thread dump re
Taking thread dumps in production
My application uses some third-party libraries. I need to log some exceptions that occur inside lib (e.g. exceptions about read file), but these exceptions are caught in the same library.
Is there some way I can log these exceptions myself, even if they're not logged by the library?
Look at AspectJ. You can write an advice around construction (and maybe even thrwoing) of the FileNotFoundException. Be advised though, that it will log every time the the pointcut is reached. With some expertise you will be able to control it.
EDIT: Dave Newtwon pointed at at this example which shows how easy it is to do this once you get the hang of it.
I have a large program, that i modified in java. I used the intelliJ idea (community edition) IDE for compiling. When i go to run the program, it starts up the GUI and then proceeds to do everthing i want from it, with very few problems (of which are unrelated to the exceptions). But the code always generates class not found exceptions (even the original unmodified code does this once you extract it from the .jar file. Despite these errors, it executes within the IDE perfectly, while still noting the errors, but they don't appear to have an effect on the program. However, when i execute them from within the virtual machine (with java filename) the exceptions which are usually ignored prevent the ultimate execution of the program. The errors are exactly the same as the ones that the iDE shows, but the IDE ignores them! How could i get a virtual machine to ignore the errors and execute the program (is there an option to pass to java - for example java -ignoreerrors filename).
Is this possible, or will i have to alter the code?
There's no way to ignore ClassNotFoundExceptions unless that class isn't actually needed by the code. Some frameworks do that by trying to load a class to discover whether some feature is available. However, if a CNFE is preventing your app from running, you'll just have to fix it. If you show some stack traces, someone might be able to steer you in the right direction.
If you are having trouble with ClassNotFoundExceptions then you can always localize the problem and catch and log using try { ... } catch (...) { ... }.
If you are instead getting ClassNotFoundErrors then it's not a localizable problem with reflection, but a failure to initialize code that's needed. You should try to prune unneeded dependencies but you really shouldn't use classes that haven't initialized properly.
If you absolutely have to, you can always load your program using a custom ClassLoader that generates bogus empty classes for any name that is not resolvable using the system classloader and use that to load your main class. That will replicate, to some degree, what your IDE is doing, though your IDE probably goes the extra step to make sure that partially well-defined classes have the right interface even if some methods are stubbed out because their bodies don't compile.
You can only ignore compiler warnings. You cannot ignore errors.
The errors that IntelliJ shows are coming from the same compiler.
ClassNotFoundException would indicate that your code failed to dynamically load a class at runtime.
This could mean that a required dependency (jar) is missing from your classpath. Try to consult your code documentation and make sure you've resolved all runtime dependencies. Also make sure that the dependent jars are in the classpath otherwise the runtime won't be able to find them.
I am currently having the problem that I have a (partial) program that is trying to load a class but fails because it cannot find this class. Looking at the stack trace, I cannot see any particular reason for why the VM tries to load this particular class at the first place. Are there any tools that would let me figure out why a particular class is being loaded?
Hint:
I am already getting a stack trace at the exact point where the JVM tries to load the class (through an agent). However, the stack trace contains no line numbers. Therefore I only know which method triggers the class being loaded, not which statement. Then, even knowing the statement may not be enough. A single statement can cause a class to be loaded in many ways, because sometimes the VM needs to load part of the transitive closure of classes.
Run your program with the -XX:+TraceClassLoading and -XX:+TraceClassResolution flags. This will create a LOT of output that looks like the following:
[Loaded com.kdgregory.example.memory.PermgenExhaustion$MyClassLoader from file:/home/kgregory/Workspace/Website/programming/examples/bin/]
RESOLVE com.kdgregory.example.memory.PermgenExhaustion$MyClassLoader java.net.URLClassLoader
RESOLVE java.net.URLClassLoader java.lang.Class URLClassLoader.java:188
You'll need to trace the chain of RESOLVE messages for a particular class. Or more likely, you'll see an error when your program attempts to load the class, preceeded by resolve messages for the class that loads it).
You might try a static analysis tool like JDepend to see what classes have references to that class.
Classloaders
If it's an envorinment where multiple class-loaders are in the game (like a web application) you should be careful. Please tell us what's the app.
resource
Tell us where are the jars (you file/dir structure) and what class is loading. Are you loading it dinamically using Class.forName? or using spring or another framework of IOC? Is it the main class?
Some previous testing (to help us)
Maybe you can test some things using Class.getResource() from within the main method. If you class is foo.bar.Clazz try Class.getResource("/foo/bar/Clazz.class") to see if it returns something valid or not. Try to do the same with the class that loads your failing class to see if it's where you expect.