Error handler

GNU Radio
1

Greetings,

I can see there is an error handler class in gnuradio-core / runtime /
gr_error_handler and I was wondering if there is an instance of it
created by the runtime that can be used by the blocks and maybe the
applications? So far I have only found fprintf’s for error messages
though I haven’t looked everywhere.

Alex

2

On Sat, Apr 16, 2011 at 6:11 PM, Alexandru C. [email protected]
wrote:

Greetings,

I can see there is an error handler class in gnuradio-core / runtime /
gr_error_handler and I was wondering if there is an instance of it
created by the runtime that can be used by the blocks and maybe the
applications? So far I have only found fprintf’s for error messages
though I haven’t looked everywhere.

Alex

Alex,
We don’t really use the gr_error_handler at all. All errors and warnings
are
done through either frpintf to stderr or throwing and catching
exceptions.

If you have some ideas of how to make error handling better, I’d love to
hear and discuss them.

Tom

3

On Thu, Apr 21, 2011 at 4:31 PM, Tom R. [email protected]
wrote:

Alex

Hi tom,

Thanks for the info.
For future enhancements one can consider creating a global object that
provides functions like gr_debug(), gr_error(), gr_warning() that are
accessible by both blocks and applications. Similar to what is available
in
Qt. I guess the only advantage over fprintf’s would be uniform
management
errors and debug messages that could provide controlled shut down in
case of
critical errors.

Alex

4

On Mon, Apr 25, 2011 at 5:44 AM, Alexandru C. [email protected]
wrote:

though I haven’t looked everywhere.
hear and discuss them.
critical errors.

Alex

Good ideas, thanks!

Tom

5

Alex

Good ideas, thanks!

Tom

It looks like boost has a logging facility. Its not officially part of
boost yet. It seems to be all headers files, so you could probably pull
it into gnuradio and start using it.

http://boost-log.sourceforge.net/libs/log/doc/html/index.html
http://sourceforge.net/projects/boost-log/files/boost-log-1.0.zip/download

I’m looking into something of the like for UHD and boost is often the
answer. -Josh

6

On Wed, Apr 27, 2011 at 8:59 AM, Plett, Mark L.
[email protected]wrote:

module. So we could have similar configuration files and paradigms in C++ as
Our logging wish list would look something like this:
argument for or against log4cplus vs boost.log?

Thanks,
–mp

Thanks for the input, Mark. From GNU Radio’s point of view, if we were
to
roll any of these features into the code, I would probably go with
boost,
mostly because we are already pretty heavy users of Boost and this seems
like the least change to the code. In other words, we wouldn’t have to
add
another dependency to the already long list.

Of course, if there is a really good argument for another project, we
would
have to consider it.

Tom

7

Hi Tom, Alex, and Josh,

We’ve started looking into logging for our modems as well. Currently we
use the python logging module for logging on the python side. We have
started to include the log4cplus library for logging in our blocks. We
are starting with each block having its own logger, but plan to
eventually move to one logger in a static class.

It wasn’t clear what advantages boost.log had over log4cplus. We
started with log4cplus since it has the same log4j roots as the python
logging module. So we could have similar configuration files and
paradigms in C++ as we are using in Python. Any thoughts on which
library would be a better starting point?

Regardless of which library gets used, I would advocate using one of the
already available libraries in some kind of thin GR wrapper.

Its important to our modems that we be able to remove the logging
entirely for performance. Which we can do with log4cplus. Can we do
that with boost.log as well?

Our logging wish list would look something like this:

  1. The usual logging features, rolling files, level filtering, various
    output streams, file, socket, stdout etc…
  2. One module for logging in python and C++
  3. One module for logging across separate blocks
  4. Logging easily disabled from the build so we can easily control the
    trade-off between performance and debug.

Our current plan is to roll our own logging with the log4cplus library.
Is anyone signing up to take on logging for gnuradio? Does anyone has a
clear argument for or against log4cplus vs boost.log?

Thanks,
–mp