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

WebSocketConnectable throws IOException not available in catch #59

Open
davidwynter opened this issue Jan 4, 2018 · 1 comment
Open
Assignees

Comments

@davidwynter
Copy link

davidwynter commented Jan 4, 2018

I have this code:

`
CSHttpApp csHttpService = null;

try {	

	csHttpService = (CSHttpApp) initiconnectable
				.connect((res, err) -> logger.error(initiconnectable + " not connected!")).await();

	csHttpService.setHostAddress(cshostname);

} catch(AwaitException ae) {

	String errMsg = "Service " + cshostname + " has exception connecting to the Failover main service - " + ae.getMessage() + "\n";

	logger.error(errMsg);

	notStarted.add(errMsg);

}

`

If the csHttpService is not available then it throws an exception that I cannot add a catch statement for, "Unreachable catch block"

java.lang.RuntimeException: java.io.IOException: UT003035: Connection timed out at org.nustaq.kontraktor.remoting.websockets.JSR356ClientConnector$WSClientEndpoint.<init>(JSR356ClientConnector.java:105) at org.nustaq.kontraktor.remoting.websockets.JSR356ClientConnector.connect(JSR356ClientConnector.java:73) at org.nustaq.kontraktor.remoting.base.ActorClient.connect(ActorClient.java:72) at org.nustaq.kontraktor.remoting.websockets.WebSocketConnectable.lambda$connect$0(WebSocketConnectable.java:69) at org.nustaq.kontraktor.remoting.websockets.WebSocketConnectable.connect(WebSocketConnectable.java:80) at org.nustaq.kontraktor.remoting.base.ConnectableActor.connect(ConnectableActor.java:50) at uk.co.example.quokka.InitServicesHelper.initFailoverApps(InitServicesHelper.java:175)

I'd prefer to catch it.

@RuedigerMoeller
Copy link
Owner

hum :) ..
AFAIk in this scenario it can be signaled back via rejecting a promise only. As sloppy programming frequently does ignore async errors (result,error) -> if ( result != null ) .. diagnostics with cluster startup failures was hard, so I forced dumping of those :).

will address with one of the next minor releases

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

No branches or pull requests

2 participants