FileNotFoundException thrown but ignored using SQLite + PUREJAVA on Mac

Elements
, , ,
1

Very strange “problem” I’m seeing with an experimental project, using SQLite with PUREJAVA.

I am creating my own wrapper around SQLite which adds things like parameterised queries (including support for named parameters even in PUREJAVA usage). It is going well :). I already have a single-source console app which compiles and runs on .NET, OS X and as a Java console app on both Windows and Mac.

But I see an odd error when running the Java console version on a Mac.

At the point at which this is called:

&Class.forName('org.sqlite.JDBC');

A FileNotFound exception is thrown, with a message (in the console output) saying it will be ignored. The first time this happened I halted the app and tried to figure out where my JDBC environment was messed up. Eventually I concluded that it wasn’t, and tried again (yes, I am occasionally insane).

I got the same error, but this time, since it said it was going to be ignored, I decided to ignore it and chose to continue running. I then got several more occurrences of the same (or similar) FileNotFoundException but the program otherwise continued as normal and produced the correct output.

Finally there was also then a fatal exception that occurred right at the end, after all my program code had completed.

The same Java console app compiles and runs on Windows without any grumbles.

The only “file” explicitly being referenced by my code - the database file - is clearly being found, and the SQLite JDBC driver must be being located otherwise the program simply wouldn’t function and certainly wouldn’t produce the right output from the query (but it does). That and the fact that the errors were triggered by the Class.forName call suggests it is something in my JVM installation or application package ? But what ?

Has anybody ever seen anything remotely similar to this ?

I suspect it is primarily a Java environment issue rather than Oxygene/Elements/Fire or even Mac specifically.

2

OK, I don’t know what I was searching for last night but I was coming up empty handed. But my search terms now I think may have found a plausible explanation and it seems it may be compiler (or debugger) related after all.

It seems I’ve (re)discovered checked exceptions.

What I don’t understand is why the Java code produced for Windows is (perhaps) different than that produced for OS X, except that one was compiled with Visual Studio, the other with Fire. Is one producing code which implicitly declares the throwing of FileNotFoundException exceptions where the other is not ? Is one producing code which catches and handles these exceptions where the other is not ?

If the compiler output is the same, could it be a difference in behaviour in the debuggers ? i.e. is the Visual Studio debugger simply “swallowing” unhandled checked exceptions where the Fire debugger is reporting them ?

Unfortunately I don’t have my Mac with me at the moment otherwise I would try to create a MCVE to demonstrate the difference I am seeing, but hopefully there is enough info above to be thinking about until I can put together such an example.

3

Having just tried to reproduce the problem on another machine (the exact same solution, same build of Fire) and things are slightly different.

I still get the FileNotFoundException errors in the console output but they do not interrupt the debugger.

Also, I have determined that the cause of the final, fatal exception I mentioned is a readLn call that is intended to keep the console window hanging around so that I can see the output. Obviously this is not an issue in Fire where that output is captured to the debug console rather than the app running in a terminal window.

I’m not sure how common it might be to need to make the distinction, but it might be useful to have a conditional symbol defined that could be tested for compilation under Fire, if it doesn’t already exist ?

{$if not FIRE}
  readLn;
{$endif}

For now I can just ignore the exception so no real biggy. :slight_smile:

But now I’m trying to understand why the FileNotFoundException’s are causing different behaviour on my other Mac (beta build 1991 of Fire in each case). Is there some setting somewhere that might be having an influence ? :thinking:

4

Problem solved, but still very strange.

The difference in behaviour is explained by the “Stop on Exceptions and Signals” option in the Debug menu of Fire. With this ON on my MBP, then I get the halting behaviour from the FileNotFoundException’s. With it OFF then it behaves in the same way as my iMac.

But the odd thing is that the iMac behaves in the same way regardless of this setting. It was never breaking on Exceptions and Signals.

But I have my explanation and it’s not a major problem right now so I’m not going to investigate further. :slight_smile:

5

Oke so the way it acts is quite weird. It should break on exceptions/signals on your imac unles that option is off.

The exceptions are expected though, that’s just the way of Java, they throw a lot of them.

6

Yep. And of course the reason things appear different in Visual Studio is that in that case those exception messages appear in the debugger output, not the console window hosting the application itself.

Is there any work in hand towards achieving the same arrangement in Fire ?

i.e. when debugging a console application having that application running in a terminal, separate to the debugger console ? That presumably then would also deal with whatever the issue is with readLn() ?