When running from console we'd expect a process exit code of zero when all is okay and something non-zero (for stupid batch files preferably a positive number like 1) when the chm file is not generated.
If you want to implement this and you are are willing to do some refactoring I'd recommend that you only catch exceptions at the highest level so that you can decide what to do about the error from where the call was placed. Otherwise without refactoring you can place global variable that stores whether an error has happened and set that when an exception was caught (but i think this is a hack).
To test this, call the app from console like this:
ChmProcessor.exe /g /y /q x.WHC && echo ok
If you have the chm file in the reader it cannot be overwritten so you should not see ok being printed. If all goes okay you should see ok printed.
Emmm.. It seems the standard is 0 for all ok and non zero for something wrong:
http://stackoverflow.com/questions/1101957/are-there-any-standard-exit-status-codes-in-linux
http://stackoverflow.com/questions/11309675/what-are-the-default-values-that-can-be-passed-to-environment-exit-method
Ill check the log generation. Something like: If there is error messages, it will return 2, if there is warnings 1, and 0 otherwise.
Done. It will be in 1.7.1. Codes are 0= ok, 1= warnings, 2= errors