RE: error handling
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. Regards, Roland
Re: error handling
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. It is. The problem is that FOP can't delete the output file in case of a problem if it only gets an OutputStream. And for optimization reasons FOP can't wait until the end to write the output to the target stream. But does fop should delete output file? I don't think so, that's responsibility of enclosing application, which has full control of OutputStream and can easily do this being catching FOPException. All very well for embeddding, but the command prompt version still leaves the corrupt file there no file at all would be preferable to a useless one. I hope the UNIX script sets the return code on errors (haven't tested yet). Cheers, Jeremias Märki
RE: error handling
Don't know about UNIX but on Windows it seems that the return code is always 0. Regards Con -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Monday, June 17, 2002 08:23 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: error handling 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. It is. The problem is that FOP can't delete the output file in case of a problem if it only gets an OutputStream. And for optimization reasons FOP can't wait until the end to write the output to the target stream. But does fop should delete output file? I don't think so, that's responsibility of enclosing application, which has full control of OutputStream and can easily do this being catching FOPException. All very well for embeddding, but the command prompt version still leaves the corrupt file there no file at all would be preferable to a useless one. I hope the UNIX script sets the return code on errors (haven't tested yet). Cheers, Jeremias Märki
Re: error handling
Roland Neilands wrote: All very well for embeddding, but the command prompt version still leaves the corrupt file there no file at all would be preferable to a useless one. Well, I believe it's feasible, but anyway this behaviour should be parametrizable. -- Oleg Tkachenko Multiconn International Ltd, Israel
Re: error handling
It is. The problem is that FOP can't delete the output file in case of a problem if it only gets an OutputStream. And for optimization reasons FOP can't wait until the end to write the output to the target stream. On 14.06.2002 21:21:48 Oleg Tkachenko wrote: Ruane, Conleth wrote: I'm using the latest version of FOP to automatically generate pdf files from xml (what else) and I've noticed that when fop stops due to errors in the input file(s) a corrupt pdf file is generated. Is there any way I can prevent this or is there any way I can access a FOP exit code so that I know that something went wrong. Currently my only option is to grep the output for errors and react on that. Any suggestions welcome. Driver's render() and run() methods are declared to throw FOPException - is it not a correct way to report errors? -- Oleg Tkachenko Multiconn International Ltd Cheers, Jeremias Maerki
Re: error handling
Jeremias Maerki wrote: It is. The problem is that FOP can't delete the output file in case of a problem if it only gets an OutputStream. And for optimization reasons FOP can't wait until the end to write the output to the target stream. But does fop should delete output file? I don't think so, that's responsibility of enclosing application, which has full control of OutputStream and can easily do this being catching FOPException. -- Oleg Tkachenko Multiconn International Ltd
RE: error handling
It is. The problem is that FOP can't delete the output file in case of a problem if it only gets an OutputStream. And for optimization reasons FOP can't wait until the end to write the output to the target stream. But does fop should delete output file? I don't think so, that's responsibility of enclosing application, which has full control of OutputStream and can easily do this being catching FOPException. All very well for embeddding, but the command prompt version still leaves the corrupt file there no file at all would be preferable to a useless one. I hope the UNIX script sets the return code on errors (haven't tested yet). Regards, Roland
Re: error handling
Ruane, Conleth wrote: I'm using the latest version of FOP to automatically generate pdf files from xml (what else) and I've noticed that when fop stops due to errors in the input file(s) a corrupt pdf file is generated. Is there any way I can prevent this or is there any way I can access a FOP exit code so that I know that something went wrong. Currently my only option is to grep the output for errors and react on that. Any suggestions welcome. Driver's render() and run() methods are declared to throw FOPException - is it not a correct way to report errors? -- Oleg Tkachenko Multiconn International Ltd
