[Ipopt] Catch (...) statements in Ipopt

[David Wilkinson]

Thanks for this.

I thought I had searched for all references to rethrow_nonipoptexception_ in the 
source code. Maybe I missed this one because the method 
IpoptApplication::RethrowNonIpoptException() is defined inline in the class 
definition. Sorry about that.

The one unprotected occurrence of catch (...) in IpoptApplication.cpp is in the 
IpoptApplication constructor, and so cannot be protected by the 
rethrow_nonipoptexception_ value (because this value is always false there). A 
global mechanism such as a preprocessor setting would be needed. But perhaps 
this occurrence in the constructor is not important (it was certainly not one of 
those that gave our application trouble).

This rethrow_nonipoptexception_ mechanism did not exist in the Ipopt 3.8.3 that 
we were using before, so we had to modify the source code to rethrow non-Ipopt 
exceptions.

Thanks again,

David Wilkinson

=========================

Stefan Vigerske wrote:
> Hi,
>
> you can change the value of rethrow_nonipoptexception_ via
> IpoptApplication::RethrowNonIpoptException():
>
> https://www.coin-or.org/Ipopt/doxygen/classIpopt_1_1IpoptApplication.html#a985d4b2f4b443b7aef8d6e924c49b5ce
>
>
> Best,
> Stefan
>
> On 05/13/2017 12:47 PM, David Wilkinson wrote:
>> I have a Bonmin/Ipopt client application that (rightly or wrongly) uses C++
>> exceptions for flow control in abnormal situations. In some of these
>> situations, the exception is getting caught by catch (...) statements in
>> Ipopt::IpoptApplication. The content in some (but not all) of these catch
>> (...) statements is protected by a variable rethrow_nonipoptexception_, but
>> this variable is hard-wired to be false, and so cannot be used to change
>> behavior without modifying source code.
>>
>> Suggestion:
>>
>> The content of all occurrences of catch (...) in Ipopt::IpoptApplication
>> should be protected by this rethrow_nonipoptexception_ variable, and its
>> value should be controllable by a preprocessor symbol.
>>
>> There are examples of catch (...) statements in other parts of COIN-OR (Bonmin
>> and Clp) that are not harmful to my client application, but perhaps these
>> should also be protected in a similar manner.
>>
>> Thanks,
>>
>> David Wilkinson
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_ipopt&d=DwICAg&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=BRcuJnQr5NAzU29t80hk2rsLc4vrlRySBDabuq0O1ZI&m=uUZR1xuZjRHb2iwG1M6a4OZH7EZH4pOHxKw1tfWL5TE&s=_8Ow3ENlrd9SRhRDClaTgphGxyICFFwa7JbRD6uhG6o&e=
>>
>
>