#429: Add option to disable warnings in modules --------------------------+------------------------------------------------- Reporter: kyngchaos | Owner: [email protected] Type: enhancement | Status: new Priority: minor | Milestone: 6.4.0 Component: default | Version: svn-develbranch6 Resolution: | Keywords: Platform: Unspecified | Cpu: Unspecified --------------------------+------------------------------------------------- Comment (by glynn):
Replying to [ticket:429 kyngchaos]: > I would like to be able to suppress warning messages in commands, yet keep messages based on the GRASS_VERBOSE level, especially in raster projection (r.proj) where is possible to get thousands of "pj_transform() failed: tolerance condition error" warnings, depending on the projection, that are expected but clutter the progress output and slow down the process. The correct solution here is as others have suggested: limit the number of warnings from a single source rather than disabling them completely. The main problem with pj_do_proj() and pj_do_transform() is that the same G_warning() call is used to report any and all error conditions from pj_transform(). Some may be more serious than others, so printing a fixed number of warnings could result in harmless warnings being shown but more serious ones being suppressed. A more robust solution is to record the last error code, and suppress multiple consecutive occurrences of the same error. If you get a different error, you generate a warning for it. This will still produce a flood if you get alternating errors, but avoiding that is awkward, requiring e.g. an array containing a flag for each error code. > I see that G_warning() has a companion G_suppress_warnings(), so this at least was an intended possibility at one time (but maybe deprecated or discouraged now?). It's a band-aid for library functions which generate too many warnings. I suggest removing it in 7.0. If there are cases where the library should normally produce a warning (because it's unrealistic to require programmers to manually check for rare errors) but cases where it needs to be disabled, there should either be a "nowarn" flag or a corresponding function to suppress a specific warning. The existing usage means that code which uses G_suppress_warnings() around e.g. G_read_colors() to suppress the "colour support ... missing" warning (which is harmless; you just get the default rainbow colour table) could also suppress more significant warnings. -- Ticket URL: <http://trac.osgeo.org/grass/ticket/429#comment:7> GRASS GIS <http://grass.osgeo.org>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
