Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing additional exception information for better clarity #392

Closed
wants to merge 1 commit into from

Conversation

matthiasrichter
Copy link
Contributor

I have been trying to help @tklemenz with debugging a qc workflow. There is an unhandled exception

[8009:QC-TASK-RUNNER-Clusters]: [19:10:11][ERROR] Unhandled exception reached the top of main: Object not found error, device shutting down.

which I wanted to understand. Since there is no further name string in the exception message my first assumption was that the methods are called with an empty string. But then I found that the implementation of of AliceO2::Common::ObjectNotFoundError drops additional information and for clarity we better skip writing more details into the exception until this is fixed.

https://github.com/AliceO2Group/Common/blob/3f92059e08f191ce6c65a5a9a119e5aba02b89ec/include/Common/Exceptions.h#L28

We can also take this suggestion as a trigger to fix the implementation in AliceO2/Common and maybe even add a sanity check for the arguments in stopPublishing/getMonitoObject to make the exception message more usable.

Last but not least, I suggest to handle the exception on the level of the QC framework, and only rethrow with additional information if the condition is really fatal.

@Barthelemy
Copy link
Collaborator

Barthelemy commented May 12, 2020

Hi Matthias,

I agree with most of it. I will try to translate it in corresponding issues in JIRA and will point to them from here.

  1. Fix AliceO2::Common::ObjectNotFoundError (https://alice.its.cern.ch/jira/browse/O2-1416)
  2. add a sanity check for the arguments in stopPublishing/getMonitoObject (https://alice.its.cern.ch/jira/browse/QC-333)
  3. Reconsider the rethrowing of exceptions in QC (for non fatal exceptions) (https://alice.its.cern.ch/jira/browse/QC-334)

It seems that there is a problem with this PR.

Cheers,

Implementation of of AliceO2::Common::ObjectNotFoundError drops additional
information and for clarity we better skip writing more details into the
exception until this is fixed.

https://github.com/AliceO2Group/Common/blob/3f92059e08f191ce6c65a5a9a119e5aba02b89ec/include/Common/Exceptions.h#L28
@matthiasrichter
Copy link
Contributor Author

Thanks, I think if especially https://alice.its.cern.ch/jira/browse/O2-1416 is expected to be fixed very soon we can also drop this PR.

PS: there was a typo, now the compilation works.

@Barthelemy
Copy link
Collaborator

Having another look at it, it seems that the implementation does not drop additional information. If I cout an ObjectNotFound exception I get:

/Users/barth/dev/alice/sw/SOURCES/Common-O2/master/0/test/testExceptions.cxx(17): Throw in function void foo()
Dynamic exception type: boost::wrapexcept<AliceO2::Common::ObjectNotFoundError>
std::exception::what: AliceO2::Common::Exception
[AliceO2::Common::errinfo_object_name_*] = objectName

This being said, I understand that FairMQ / DPL (?) prints the what() and thus we miss the object name. I have prepared this PR to fix it : AliceO2Group/Common#36
If you agree with it, we can drop this PR as you suggest.

@matthiasrichter
Copy link
Contributor Author

Indeed, the problem is the implementation of ObjectNotFoundError::what, sorry for not being clear enough. I think in the end we should close this PR if the cause of the issue is fixed. I just want to make sure that all what is intended to be the output of the exception ends up in the message.

One comment on AliceO2Group/Common#36, as it is right now one would need to wrap the actual object name into errinfo_object_name, right? So I can adjust this PR accordingly, if you want to keep it like that, see my comments there.

@Barthelemy
Copy link
Collaborator

The latest versions of O2 and QC should provide the full details of the exceptions including the stack trace. This is also the case if the exception escapes the QC framework (ie. reaches the DPL driver).

Therefore I am going to close this issue. Feel free to reopen if you think that something has actually not been addressed.

@Barthelemy Barthelemy closed this May 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants