First place to lool is of course: org.apache.fop.apps.Fop.java. I think we only need to set a few System.exit(-1), or so, in the catch statements there. If there's too little Java knowledge or some other problem, please add a bug report to bugzilla for me. I'll then try to look at it as soon as possible. This will be a little one to fix. http://nagoya.apache.org/bugzilla/ By the way, on Windows you can test the return code of the last executed program using IF ERRORLEVEL... (See Windows help for more info) > >> You're right. The command line wrapper can and probably should delete > >> the target file in case of an error. Could you check if the > >> return code > >> is set on the command line? If not, we should fix that. > >> Jeremias Märki > > > Don't know about UNIX but on Windows it seems that the return > > code is always 0. > > > > Regards > > Con > > Sorry about the delay, my Solaris test box was reconfigured. > The return code is not set by FOP on Linux: even appending: > exit $? > to fop.sh makes no difference as FOP itself returns 0 regardless. > > NB: running 'java' with no parameters does return error code 1. > > I have no idea how to set or check DOS return codes.
Joerg, You beat me to this one. I was about to commit a change with one slight difference: I use System.exit(2) for the FileNotFoundException. Do you want to do that, or does it make your runtests changes problematical? pbw
This should be almost fixed now in the CVS maintenance branch, apart from problems with AWT renderer. Exit code is 1 if the input file (.fo or .xml) was not found and 2 in case of a FOP problem. Runtime exceptions are not yet caught, I think. The output file is also deleted in case an exception is thrown.
Fixed in 0.20.4.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed