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

Adapt to Exceptions being thrown in postRead/postWrite #130

Closed
7 tasks
killenb opened this issue Apr 3, 2020 · 6 comments
Closed
7 tasks

Adapt to Exceptions being thrown in postRead/postWrite #130

killenb opened this issue Apr 3, 2020 · 6 comments
Assignees

Comments

@killenb
Copy link
Member

killenb commented Apr 3, 2020

Depends on ChimeraTK/DeviceAccess#117
Child of #123

After the changes in ChimeraTK/DeviceAccess#177 the exceptions are not thrown in doXxxTransferYyy() anymore, but in postRead() and postWrite(). The ExceptionHandlingDecorator is not working any more because it is still trying to catch in the transfers but not in in the post actions. It needs to be adapted accordingly.

The task of this ticket is not to implement the new specification, but to make the ExceptionHandlingDecorator work the same way it did before.

  • change all overloads of doXxxTransfer so they simply call NDRegisterAccessorDecorator<USER_TYPE>::doXxxTransfer(). Don't remove them, they will be needed later.
  • rename ExceptionHandlingDecorator::hasSeenException to previousReadFailed. It has a name conflict with TransferElement::hasSeenException.
  • Change genericTransfer() to genericPostAction().
try{
  callable();
}catch{ChimeraTK::runtime_error &e){
  TransferElement::hasSeenException=true;
  activeException=e;
}
setOwnerValidity(TransferElement::hasSeenException);
if (TransferElement::hasSeenException){
  reportException(activeException.what());
  hasSeenException=false;
  waitForRecovery()
}
  • override doPostRead() and doPostWrite() such that they call doGenericPostAction()

  • add waitForRecovery() to doPreWrite() (after writing to the recovery accessor, but before calling the inherited NDRegisterAccessorDecorator<UserType>::doPreWrite()

  • add an override for doPreRead() which does waitForRecovery() and then calls NDRegisterAccessorDecorator<UserType>::doPreRead()

  • All tests should now pass again without modification

@jhktimm
Copy link
Contributor

jhktimm commented Apr 14, 2020

Do you realy mean overload doPostRead() and doPostWrite() and that without function arguments?
Or override?
I have th esame question with doPreRead()!?

@killenb
Copy link
Member Author

killenb commented Apr 14, 2020

Do you realy mean overload doPostRead() and doPostWrite() and that without function arguments?
Or override?
I have th esame question with doPreRead()!?

just updated the ticket description. I certainly did mean 'override'

@jhktimm
Copy link
Contributor

jhktimm commented Apr 15, 2020

I also changed in DeviceAccess device_backends/include/TransferElement.h
hasSeenException and activeException from private to protected for this ticket.

@killenb
Copy link
Member Author

killenb commented Apr 15, 2020

Blocks #131. Make it readyForImplementation when closing this ticket

jhktimm added a commit that referenced this issue Apr 15, 2020
	TODO doGenericPostAction
	DONE all the rest

	does not compile, due to missing overrides
jhktimm added a commit that referenced this issue Apr 15, 2020
jhktimm added a commit that referenced this issue Apr 15, 2020
@killenb
Copy link
Member Author

killenb commented Apr 16, 2020

The idea with the genericPostAction does not work. You need phase 1 of #138

jhktimm added a commit that referenced this issue Apr 16, 2020
@killenb
Copy link
Member Author

killenb commented Apr 16, 2020

I also changed in DeviceAccess device_backends/include/TransferElement.h
hasSeenException and activeException from private to protected for this ticket.

Should we take this back? I think there was a reason to have it private and the implementation does not need it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants