I'm using Poco 1.6.0 and the Util::ServerApplication
structure.
At the start of int main(const ArgVec& args)
in my main class, I redirect all the logging to a file:
Poco::AutoPtr<Poco::FileChannel> chanFile = new Poco::FileChannel;
chanFile->setProperty("path", "C:\\doesnotexist\\file.log");
Poco::Util::Application::instance().logger().setChannel(chanFile);
If the log file cannot be opened, this causes an exception to be thrown, which I catch, and return an error code from main()
. The Application::run()
code in Poco's Application.cpp
then calls Application::uninitialize()
.
The implementation of Application::uninitialize()
iterates through each SubSystem executing that subsystem's uninitialize()
.
But one of those is LogFile::uninitialize()
, which causes the following message to be logged: Uninitializing subsystem: Logging Subsystem
.
When it attempts to log that message, an exception is thrown since the log file could not be opened (for the same reason as before). That exception is caught somewhere in Poco's code and it attempts to log an error, which causes an exception, and that one finally terminates the program.
How should I deal with this issue? E.g. is it possible to tell the logging subsystem to not throw any exceptions?
There seems to be a greater issue too; if any subsystem uninitialize()
throws, this will cause execution to leave the subsystem shutdown loop in Application.cpp
, so other subsystems will not have a chance to shut down either.
You should make sure that the path exist before setting up the file channel, e.g.:
Application::unitialize()
will loop through subsystems and log iterations as debug messages - the idea is to catch problems before release.UPDATE: as pointed in the comments, the directory may exist at the time of the check but may not exist (or not be accessible) afterwards, when logging actually happens. There is nothing in Poco that shields user from that; so, you will have to make sure the directory exists and is accessible throughout the lifetime of the FileChannel using it. I have not found this to be an obstacle in practice. I did find the initial non-existence of a directory to be an annoying problem and there is a proposal for addition of such (optional/configurable) feature but it has not been scheduled yet for inclusion in upcoming releases.