6

I doubt such a thing is possible, but without attaching a debugger to a java application, is it possible to have some collection populated with information about every exception that is generated in a java application, regardless of if it is caught or not? I know that in .NET, messages get generated by the application about exceptions which at that point are called "First Chance Exceptions", which may or may not subsequently be handled by the application. I'm wondering if there might be a similar mechanism in java I can exploit to view information about all the exceptions generated at runtime.

Just to clarify. This has nothing to do with the context in which an exception occurs. This question is not about what I do in a catch block, or unhandled exceptions. Its about knowing if the JVM provides a mechanism to see every exception generated at runtime, regardless of what generated it, or the context.

Mark W
  • 2,791
  • 1
  • 21
  • 44
  • Why would you not want to catch an exception? If its caught just add the stacktrace to log4j or something similar? – user1231232141214124 Aug 22 '14 at 16:12
  • 1
    We have a client who has it stuck in his head that he can get meaningful information out of a complete list of exceptions generated by our application, regardless if they are unhandled or not. We also want to avoid refactoring large portions of our code base to do something like what you suggested, and capture data bout exceptions in every try statement. – Mark W Aug 22 '14 at 16:14
  • You should edit your original question and add that info – user1231232141214124 Aug 22 '14 at 16:23
  • 1
    Maybe this helps: http://stackoverflow.com/questions/23561555/java-exceptions-counter-on-jvm-hotspot – Absurd-Mind Aug 22 '14 at 16:53
  • @Absurd-Mind While im not 100% on this, the linked question requires the use of -agentlib, which enables debugging connections on the JVM. Ive seen similar implementations which silently inject breakpoints into the application to capture data about Exceptions. I don't really feel comfortable doing this type of thing, but +1 for the link. – Mark W Aug 22 '14 at 16:59
  • If you only want to show your customer what happens, then `-agentlib` is the way to go. If you need this at all time and also in production then maybe editing every catch clause would be better (This could be done fairly easy with search and replace) – Absurd-Mind Aug 22 '14 at 17:04
  • @Absurd-Mind You are probably right, I was hoping for at best maybe some observable I could subscribe to, or similar, but its looking more and more like such a thing doesn't exist. – Mark W Aug 22 '14 at 17:06
  • 1
    Your client is deluded. Ultimately, such technical details should not be your client's concern. – Raedwald Aug 22 '14 at 17:18
  • @Raedwald Agreed, 100%. Definitely no argument from me, but I don't get to make decisions about what features we agree to :( – Mark W Aug 22 '14 at 17:20
  • `-agentlib` has nothing to do with debug connection. Java debugger is just an example of a particular agent, but not all agents are debuggers. Using an agent library is a standard way to do such things. It is much more reliable and safer than patching Java system classes. – apangin Aug 25 '16 at 21:59
  • 2
    BTW, the accepted answer is not very accurate. It intercepts exception construction, but not exception throwing. Not all constructed exceptions are thrown, and not all thrown exceptions are constructed. – apangin Aug 25 '16 at 22:01
  • That is very true @apangin. Good to point out. – Mark W Sep 20 '16 at 19:06

1 Answers1

8

Why not, it's of course possible! But firstly.. Logging all exceptions encountered by the JVM is a waste of life. It's meaningless in every sense, there could be several excetion's thrown without any significance.

But if indeed if you have no choice, you could tweak your Java to do that.

Breaking every rule of good programming, what we live for, I give you this idea:

  1. Copy the source code of java.lang.Exception from JDK sources to your project.

  2. Create a method in your Exception.java like below:

    private void logException() {
    // Your logging routine here.
}

  3. Edit java.lang.Exception to call this method logException() at the end of every constructor.

  4. Add the new java.lang.Exception to bootstrap classpath.

  5. Set your logging levels etc and run.

Put your heads up, present this to your weird client, use your diplomatic skills and scare them in few words 'we can do it.. but its your own risk'. Likely you will convince him not to use this.

Sergey Vyacheslavovich Brunov
  • 17,291
  • 7
  • 48
  • 81
Rajeev Sreedharan
  • 1,753
  • 4
  • 20
  • 30
  • I tried this, it works well enough I suppose, and just one question, is it normal to feel really dirty after doing such a thing? – Mark W Aug 22 '14 at 18:07
  • Yep, totally. This is one of the best ways to do an anti-demo. Jokes apart, by doing this you ruin the consistency of a well tested product, severely damage concurrency, added impact of untested code without exhaustive system testing (not just your code, the JVM too) and probably lot many things I'm too sleepy to think of, good night. – Rajeev Sreedharan Aug 22 '14 at 18:23