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

Handle Non-Serializable Exception Payload #2086

Conversation

cheeseng
Copy link
Contributor

@cheeseng cheeseng commented Jan 3, 2022

Set non-serializable event's payload field to None and wrapped non-serializable throwable as NotSerializableWrapperException when failed to serialize them, and print out a warning message on both the client and server side so that user can follow-up to make the related throwable or payload type serializable, if they needs them to. This approach avoid the non-serializable payload or throwable from crashing the test run.

}
catch {
case _: Throwable => false
}
Copy link
Contributor

Choose a reason for hiding this comment

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

@cheeseng We shouldn't catch Throwable, but something more specific. This will turn an OutOfMemoryError into false, for example. Any reason this isn't catching NotSerializableException?

}
catch {
case t: Throwable =>
// Restart server socket
Copy link
Contributor

Choose a reason for hiding this comment

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

@cheeseng Here's another catch of Throwable. Should this be NotSerializableException?

out.get.writeObject(event.ensureSerializable())

case e: Throwable => refresh()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

@cheeseng Here's another catch of Throwable. If you want to handle most exceptions uniformly, then I'd suggest Exception on Scala's NonFatal extractor.

copy(payload = None)

case _ => this
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

@cheeseng Seems like quite a bit of duplication. Maybe factor out a method that takes params and does this match?

socket.set(server.accept())
is.set(new SkeletonObjectInputStream(socket.get.getInputStream, getClass.getClassLoader))
tryReact()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

@cheeseng Should this loop forever in case it keeps getting an exception? At some point maybe it should exit?

@cheeseng
Copy link
Contributor Author

cheeseng commented Jan 5, 2022

@bvenners I have pushed the adjustments, do you mind to review and consider again this PR for merging?

Thanks.

catch {
case _: Throwable =>
}
socket.set(new Socket(host, port))
Copy link
Contributor

Choose a reason for hiding this comment

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

@cheeseng I would us NonFatal here. We have one in ScalaTest, and Scala has one. I suppose we should use the ScalaTest one, which predated the Scala one, for internal consistency.

@cheeseng
Copy link
Contributor Author

@bvenners I have added the pattern guard according to your comment, do yo mind to review this again?

Thanks!

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

Successfully merging this pull request may close these issues.

None yet

2 participants