[Patch v1] set program return code and improve logging
Hi all, attached is a patch the should set program return code to 1 in case of severe errors. It also changes the handling of so called MapFailedExceptions like "There is not enough room in a single garmin map..." or "Overflow of the NET1. The tile ..." These messages are now printed as severe messages via the logging system (showing the input file): Severe (MapFailedException): \ld_sp\63240003.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. The stdout contains two new messages: Number of MapFailedExceptions: 3 Number of ExitExceptions: 0 If any of the two shows a non-zero value, the program exits with return code 1. @WanMil, Steve: Please review. In Main.java I use "synchronized" to make sure that concurrent updates are handled. The System.exit() method is only used if the program is not called from another java program. The code In MapFailedException.log() tries to determine the code that caused the Exception. I hope this works in all environments? Gerd
On 06/05/14 10:24, Gerd Petermann wrote:
@WanMil, Steve: Please review. In Main.java I use "synchronized" to make sure that concurrent updates are handled.
The synchronized is not required, since int accesses are atomic and it appears that all changes to it are made via the same thread anyway. ..Steve
Hi Steve, thanks for the quick feedback.
@WanMil, Steve: Please review. In Main.java I use "synchronized" to make sure that concurrent updates are handled.
The synchronized is not required, since int accesses are atomic and it appears that all changes to it are made via the same thread anyway.
I see. Do you think the rest is okay? I am always afraid to put additional code into code that handles exceptions. I remember ugly loops caused by this. For example, someone may change logger to throw a MapFailedException. Maybe there is a better place to print the log? Gerd
On 06/05/14 14:28, Gerd Petermann wrote:
I see. Do you think the rest is okay? I am always afraid to put additional code into code that handles exceptions. I remember ugly loops caused by this. For example, someone may change logger to throw a MapFailedException. Maybe there is a better place to print the log?
I don't think that logging code should be purposely throwing any exceptions, so I wouldn't worry about that. I don't much like examining the stack trace in order to decide whether to exit() or not. Perhaps there could be another method that does not exit that the tests can call. Or a static flag that the tests can set that prevents the exit(). ..Steve
Hi Steve,
I don't much like examining the stack trace in order to decide whether to exit() or not. Perhaps there could be another method that does not exit that the tests can call. Or a static flag that the tests can set that prevents the exit().
okay, I agree that this is just a trick which might not always work. I think a new option --no-system-exit is the better alternative. Gerd
On 06/05/14 10:24, Gerd Petermann wrote:
@WanMil, Steve: Please review. In Main.java I use "synchronized" to make sure that concurrent updates are handled.
The synchronized is not required, since int accesses are atomic and it appears that all changes to it are made via the same thread anyway.
Mmmh, I have to do some nit picking: int variables need to be defined as volatile if they are accessed from multiple threads. Otherwise it is not ensured that they contain the latest change by another thread: http://www.javamex.com/tutorials/synchronization_volatile.shtml Anyhow if it is accessed and changed by one thread only it must not be declared as volatile :-) WanMil
..Steve
participants (3)
-
Gerd Petermann -
Steve Ratcliffe -
WanMil