[Insight-developers] Okay to remove protected helper function, ExceptionObject::UpdateWhat()?

[Bill Lorensen]

In this case, I defer to Brad's C++ expertise. If he says it would be
hard to create a subclass that needed this method, then I agree that
it should be removed. This discussion also points out, that we need to
be careful when we create and accept an API. Even the subtle
difference between a protected and private method is subject to review
and in the future may cause such a discussion to reoccur.

Sorry to be a PIA about this, but "We take it out and wait for a user
to complain" should not be part of ITK's backward compatibility
policy.

Bill

On Tue, May 27, 2008 at 3:52 PM, Niels Dekker <niels-xtk at xs4all.nl> wrote:
> Thanks for your feedback so far, Brad and Bill,
>
> First of all, I really hope that my proposed fix
> <www.itk.org/Bug/view.php?id=7094> makes sense to you  :-)
>
> Bill Lorensen wrote:
>>
>> Is there a technical reason why we
>> should not keep the method?
>
> Brad's original ExceptionObject::UpdateWhat() took care of keeping m_What
> up-to-date, whenever other exception data members (m_Description,
> m_Location) were changed.  (m_What contains the text returned by what().)
>  Unfortunately this function could itself not be made exception safe: When
> UpdateWhat() would fail (typically because of a memory failure), the text of
> m_What would no longer correspond to the other data members.
>
> My proposed fix would solve this issue (and other issues), by having all
> exception data stored together within an internal, "immutable",
> reference-counted ExceptionData object. Thereby the Set functions would
> become slightly more expensive, because they would have to replace the whole
> ExceptionData at once. But the copy constructor and the assignment would
> become very efficient, and moreover, those functions would become
> non-throwing.  (Because those would just increase the reference counter.)
>
> So the ExceptionData object would always be internally consistent, and
> UpdateWhat() wouldn't be necessary anymore.  Of course, we could leave it
> empty. But that wouldn't trigger any /possible/ user to stop calling the
> function.  So maybe this legacy/deprecation scheme could be useful?
>
>
> Kind regards,
>
> Niels
>