/// Runs the application by performing additional initializations /// and calling the main() method. /// /// First calls initialize(), then calls main(), and /// finally calls uninitialize(). The latter will be called /// even if main() throws an exception. If initialize() throws /// an exception, main() will not be called and the exception /// will be propagated to the caller.

It seems there's a discrepancy between documentation and implementation in two ways - first, uninitialize() is not guaranteed to be called and second, exceptions are not propagated. To ensure uninitialize() gets called, it should be moved out of the try/catch block, and put into it's own before the last line, something like this:

Now, as i understand, function Application::run() can throw exception in calling function `main`. It's not good. One of the benefits of using a poco framework is that the `main` function only creates an object and calling method `run` :int main (){ Object obj; return obj.run;}

And declare the function `uninitialize` as function which can not throw exception :void Application::uninitialize() throw() {//...}Throw exception in function uninitialize as bad as throwing exceptions in destructor.

Yes, and it behaves exactly as documented - it throws only if initialize/uninitialize throw; uninitialize() is called only if initialize() call was completed.

Edsoon wrote:You can solve the problem differently:

Your solution does the same thing as the fix, except for trapping initialize() exceptions (which is in discrepancy with documentation). Why would you want to call uninitialize() if initialize() call did not complete? What exactly is the purpose of calling uninitialize in every catch block?

Edsoon wrote:Throw exception in function uninitialize as bad as throwing exceptions in destructor.

No, it is not. Application::uninitialize() is not called automatically on scope exit.

alex wrote:uninitialize() is called only if initialize() call was completed.

Yes, the same behavior have classes in c++ (destructor called only if constructor completed). But if constructor is not completed compiler destroys all objects which created in constructor. In your case, the compiler does not "destroys" objects automatically , you should do it independently (by calling uninitialize).

alex wrote:Your solution does the same thing as the fix, except for trapping initialize() exceptions (which is in discrepancy with documentation). Why would you want to call uninitialize() if initialize() call did not complete? What exactly is the purpose of calling uninitialize in every catch block?

If function initialize () throws exception in the end of function and some objects already initialized (opened file or something else) ? Function uninitialize() should uninitialize objects which initialized in function initialize() (close file or something else).I showed that the function uninitialize() must be called always.

alex wrote:No, it is not. Application::uninitialize() is not called automatically on scope exit.

Edsoon wrote:But if constructor is not completed compiler destroys all objects which created in constructor.

Since we're talking analogy to C++ then let's take into consideration that, just like initialize/uninitialize, constructor/destructor are functions and the latter does not get called unless the former has completed.

Edsoon wrote:compiler does not "destroys" objects automatically , you should do it independently (by calling uninitialize).

you can do it independently without calling uninitialize() or you can call uninitialize() explicitly from your code if initialize() throws.

That argument can be applied to any arbitrary function that may throw. It is well documented what the code does. If you are not happy, then fork, work and send pull request. At this point, I'm not yet convinced that there's something wrong with the most recent change and it will go into 1.5.2 as it is.