2

I apologize in advance if this has been covered elsewhere, but the vague/common terms involved means that I found a lot of irrelevant hits and nothing that was helpful. Since my project is rather large I don't think it'd be reasonable for me to provide a M(N)WE, so instead I'm looking for ideas as to what else to check. Here's the code block:

try {
    myClassObject = new MyClass(string1, string2, string3, otherClassObject); (1)
    System.out.println("Test"); (2)
} catch (Exception e){ 
    System.out.println(e.getMessage() + " " + e.getStackTrace()); (3)
}

My constructor(1) is never called. However, neither (2) nor (3) are called (i.e. the test string is never printed nor is an exception ever printed). From my understand of a try-catch block, this shouldn't be possible.

I use Eclipse's debug mode and am able to step over that line. All 4 objects are defined and can be printed just fine (so it's not an access issue). All 4 objects have their expected value when viewed in debug mode. However, debug mode skips from (1) on to the rest of my code, never hitting (2) nor (3). A debug point placed in the constructor for MyClass is never reached.

I can call a default constructor of MyClass in place of the 4 parameter constructor and it behaves as desired. I can then copy/paste the contents of the 4 parameter constructor after (2) and all 4 parameters set properly and the object is created as desired. Obviously this is a viable work-around, but I can't find a reason that the 4 parameter constructor is failing.

In short, I have no idea how this is possible, let alone how to stop it from happening.

Edit: I've performed clean -> build -> debug on the code several times, so I'm fairly confident it is not a .class issue. Just in case I deleted the .bin and refreshed, which had no effect.

JuniorIncanter
  • 1,569
  • 2
  • 16
  • 27
  • 1
    I presume you debug a .class file (byte code) that is not synchronized with your source. Remove `bin` manually, hit F5. – Aubin Apr 01 '13 at 19:36
  • try to create new project then try to debug it. There may be a cached value causes unsynronized files – Ahmet Karakaya Apr 01 '13 at 19:38
  • I agree with previous comment. You can use `Project / Clean...` from your eclipse menu – Brad Apr 01 '13 at 19:40
  • As we are computer engineer, do not hesitate to use "restart" in case of emergency – Ahmet Karakaya Apr 01 '13 at 19:44
  • Remaining possibilities are that either the constructor of MyClass to catch another exception or another exception to throw different from Exception. – Mihai8 Apr 01 '13 at 19:45
  • Deleting neither the bin nor Project / Clean... fixes the issue. I repeatedly used Project / Clean... during the attempted debugging process. I'll attempt the other suggestions. Further, the constructor of MyClass does not throw any Exceptions. Even if it did, it is never being called (or at least that's what Eclipse is telling me) as when stepping through in debug mode, I never enter MyClass's 4 parameter constructor, nor is the breakpoint in that constructor ever triggered. Thank you for the time so far. – JuniorIncanter Apr 01 '13 at 19:49
  • try catch Throwable instead and add a finally block (print something in there) – NeilA Apr 01 '13 at 19:54
  • mmc18, if you'd like to separate your answer I can give you credit, that fixed the issue. I did not expect that as possible with Project / Clean... being used and I'm not sure exactly what a new project would be missing that a Project / Clean... doesn't remove. – JuniorIncanter Apr 01 '13 at 20:01
  • It might be possible that your constructor of MyClass Throws Exception. – Vishal K Apr 01 '13 at 20:18

1 Answers1

0

Could there be an error which does not implement Throwable and therefore cannot be caught? What are you doing in the constructor? For instance ChuckNorris Exception :) Uncatchable ChuckNorrisException

Community
  • 1
  • 1
Nuri Tasdemir
  • 9,720
  • 3
  • 42
  • 67
  • Creating a new project fixed it. For reference, though, my constructor was just calling 4 sets, one on each parameter. Even if it was throwing an error however, I think debug mode would still have allowed me to step through and see the error being throw. – JuniorIncanter Apr 02 '13 at 14:56