I would have to disagree with Andre’s advice to custom code FTP services in Java. One of the advantages of using Integration Server is the pre-built [and tested/supported] services that come out of the box. Using pre-built services means that other developers [who maybe are not Java gurus] can come along and easily (visibly) understand what your code does, and how to make changes.
While I’m not saying this is always the case, I have seen quite a number of projects become overly complex and unsupportable by ignoring built-in services and reconstructing everything in Java. One of the big positives of using webMethods software is the quick implementation times, re-working (and re-testing) everything from ground up often leads to delays. I have seen numerous customers implement extensive FTP integrations using the built-in services very successfully.
So, back to your original question. You say that some errors result in a blank lastError, do you know which particular errors cause this situation? You may be best to log the issue with technical support once you isolate what particular errors cause this situation. I did find one fix to 6.0.1 that sounds similar, does this match what you are seeing? [if so, mention it in your support request and ask if a fix for 4.6 exists]:
If there is an error in a transformer, the service pub.flow:getLastError may incorrectly return a null when it should return a lastError object.
This happens if there a multiple transformation in a MAP step and one of the transformations before the last transformation raises an error. Subsequent transformation which complete successfully clear this error which causes the pub.flow:getLastError service to incorrectly return null."