is there some way to elevate the normal pyroot errors to python exceptions, and to get rid of the output to stderr? This would be much more aligned with what normal python modules do.
Hi,
what are “normal pyroot errors” in your view? If these are messages coming from C++ libraries, then it’s not going to be easy (not impossible either, but basically the contents of the messages need to be known to delimit them and choose a properly matching Python exception). PyROOT itself does not write to stderr. It does write to stdout in two cases when mapping CINT error messages: for CINT “Note:” messages and for unknown messages.
Cheers,
Wim
For example, if you do something like
from ROOT import TFile
t = TFile('that_does_not_exist')You’ll get
Error in <TFile::TFile>: file that_does_not_exist does not existbut pyroot will continue along happily until you actually try to do something with the file.
I seem to remember some other cases where similar messages are printed. Anyway, if it’s very difficult to change there are workarounds, it just seemed worth asking to see if there was an easy fix. Thanks,
-Dan
Dan,
those are doable, since ROOT provides an error handler. I noted that PyROOT already has a handler for those errors, but only translates Warnings into Python warnings. I can’t quite figure out why I didn’t implement Errors as Exceptions as well. I’ll need to retrace my steps …
Cheers,
Wim
Hi,
Thanks, this would be useful. If raising exceptions would cause problems in existing code, it would be fine to translate root errors into python warnings as well (since python warnings are easy to turn into exceptions). But raising an exception does seem more appropriate.
-Dan
Dan,
yes, but I’m having wet feet about this one b/c the production system in ATLAS (for one, at least) greps for error strings. Something for ROOT 6.
Cheers,
Wim
That sounds perfectly reasonable. But couldn’t the default pyroot warning filter simply be set to “always”, giving the user the option to override it and throw an exception? That way ATLAS could still grep for errors, and everyone could have a python module that works as we’d expect.
I guess it sounds simple, but something could go wrong, and the last thing ATLAS needs is for their code to fail at failing. I’ll be looking forward to ROOT 6, keep up the good work!
-Dan
Dan,
hadn’t thought of that … by adding a special marker to be picked up by the filter and handled accordingly that would likely work (with some code duplication, but that’s likely to be stable).
Cheers,
Wim
Hey,
I think this would be useful to those of us who write a lot of quick plotting scripts in python and often forget to check if files have loaded. I know there are other examples of where throwing exceptions at the error would make debugging a lot easier, although I don’t have examples on hand.
If this is ever implemented I’d like to know, thanks,
-Dan
+1 for this much-needed feature. Would be nice to have this implemented upstream in PyROOT. ATLAS should not be grepping for errors… shame on them.
For now, we rootpy developers are devising a way to bypass PyROOT’s error handler that exposes ROOT errors as proper Python exceptions or as errors through Python’s logging module.
Noel
Noel,
can be done by setting the callbacks with:G__set_errmsgcallback()for cint and SetErrorHandler()for ROOT. PyROOT’s implementations live in $ROOTSYS/bindings/pyroot/src/Utility.cxx (functions ErrMsgCallback and ErrMsgHandler, respectively). Note that the CINT callback is gone in ROOT 6, and I’ll mod the latter. PyROOT isn’t functional in ROOT6 yet, so that has priority, though.
Cheers,
Wim
Hi Wim,
Thanks for the pointers. In rootpy we now have a logger that interfaces ROOT’s error handling with Python’s logging module and adds the ability to raise a certain level as a Python exception with a stack trace:
Cheers,
Noel
Noel,
ah, if there’s now an official “rootpy.org” address, then it’s high time to add a link.
Cheers,
Wim