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

TicketResolver: return failed export object instead of throwing #2845

Merged
merged 1 commit into from
Sep 15, 2022

Conversation

nbauernfeind
Copy link
Member

@nbauernfeind nbauernfeind commented Sep 13, 2022

The scope ticket resolver no longer throws an exception but instead returns an export object that is in a failed state. This allows commands downstream of a failed dependency to 1) be created, and 2) assume a dependency_failed state.

@nbauernfeind nbauernfeind added this to the Sept 2022 milestone Sep 13, 2022
@nbauernfeind nbauernfeind self-assigned this Sep 13, 2022
Copy link
Contributor

@kosak kosak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. (given my fairly limited knowledge of the server)
Thanks for diagnosing and working on this!!!!

@@ -81,7 +79,7 @@ public void teardown() {
public void testDestroyOnExportRelease() {
final CountingLivenessReferent export = new CountingLivenessReferent();
final SessionState.ExportObject<Object> exportObj;
try (final SafeCloseable scope = LivenessScopeStack.open()) {
try (final SafeCloseable ignored = LivenessScopeStack.open()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, FYI, no action required, some PL people use the variable _ (that is, single underscore) to mean "dummy" or "ignored"

Copy link
Member Author

@nbauernfeind nbauernfeind Sep 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a neat fact. I'm not sure if that was popular before Scala or not, but _ is a very heavy scala ism (where I picked the idea up). You can even use it as an unlabeled single parameter into a lambda (i.e. _.convertToInt(radix)). _ is an invalid identifier in java, so we can't do the same. IntelliJ auto suppresses unused warnings when the name is ignored.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, didn't realize _ was illegal in Java, thanks. I think I picked up the convention from Go and Rust (where _ is varying degrees of special).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason that _ is illegal is that this is coming in a future release, they wanted to reserve it to not break existing code.

https://mail.openjdk.org/pipermail/amber-spec-experts/2022-September/003485.html

As with other languages, you will be able to mark more than one local as _, and it looks like even type params will be able to be _ (as opposed to ?).

@nbauernfeind nbauernfeind merged commit 414ec5e into deephaven:main Sep 15, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Sep 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants