Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Labels:None
-
Story Points:0.5
-
Epic Link:
-
Team:Architecture
Description
Starting with devtoolset-8, gcc-8 warns about catching polymorphic exceptions by value. As far as I understand, this is a bad coding practice in general.
The occurrence I've checked regarding ip_diffim build in afw/math/Statistics.h:115 is harmless, and I'll change it as part of DM-21422.
A list of places to check are grepped and attached.
http://ptgmedia.pearsoncmg.com/images/0321113586/items/sutter_item73.pdf
In file included from /software/lsstsw/stack_20191001/stack/miniconda3-4.5.12-1172c30/Linux64/afw/18.1.0-17-gd2166b6e4/include/lsst/afw/math/Background.h:34,
|
from /software/lsstsw/stack_20191001/stack/miniconda3-4.5.12-1172c30/Linux64/afw/18.1.0-17-gd2166b6e4/include/lsst/afw/math.h:33,
|
from examples/maskedKernel.cc:2:
|
/software/lsstsw/stack_20191001/stack/miniconda3-4.5.12-1172c30/Linux64/afw/18.1.0-17-gd2166b6e4/include/lsst/afw/math/Statistics.h: In constructor 'lsst::afw::math::StatisticsControl::StatisticsControl(double, int, lsst::afw::image::MaskPixel, bool, lsst::afw::math::StatisticsControl::WeightsBoolean)':
|
/software/lsstsw/stack_20191001/stack/miniconda3-4.5.12-1172c30/Linux64/afw/18.1.0-17-gd2166b6e4/include/lsst/afw/math/Statistics.h:115:41: warning: catching polymorphic type 'class lsst::pex::exceptions::InvalidParameterError' by value [-Wcatch-value=]
|
} catch (lsst::pex::exceptions::InvalidParameterError) \{
|
^~~~~~~~~~~~~~~~~~~~~
|
Attachments
Issue Links
- relates to
-
DM-21422 Fix ip_diffim mosaic debug plots broken by Mosaic.makeMosaic signature change and compiler warning
- Done
Activity
This is not a compiler problem; the compiler is right to complain, though it's not usually a critical problem (I'd put it at about the same level as using a mutable container as a default argument in Python). I haven't seen instances of this myself, but if Gabor grepped for them it's probably worth keeping that list and fixing them.
Matthias Wittgen, is this something your clang-tidy sweeps might have already taken care of for us?
Yes. We can do one more clang-tidy run on the C++ code base and close this ticket.
Matthias Wittgen
added a comment - Yes. We can do one more clang-tidy run on the C++ code base and close this ticket. Compiling the stack with -Werror=catch-value passed. Closing this ticket as done.
Matthias Wittgen
added a comment - - edited Compiling the stack with -Werror=catch-value passed. Closing this ticket as done. 
Jim Bosch I have no idea if this is still an afw compiler problem.