I'm new to Java & its design patterns, I have a scenario like this:
Method 1 calls Method 2.
Method 2 looks like the following:
public String createUser(String username, String password) {
someApi.do(config -> {
//code here with respect to someApi.
});
}
now the trick is I need to return the value to caller which is method 1. If there are no exceptions then that is fine. However the code block inside do can throw exception, which will be handled in a separate listener class like this:
public class TestListener implements SomeApiListener {
#Override
public void exception(Throwable cause) {
}
}
Now how should I send back the exception to method 1 from this listener? I'm really confused.
it's not clear what that API do, where the listener is assigned, and what other methods it has, like if there is also onSuccess() ?
what i got from this, is that, you are dealing with async call, which usually do not return a value directly, it deals with a CallBack which in your case is SomeApiListener
So, ... I would make createUser() receives extra arg, SomeApiListener, pass the listener as anonymous inner class (with implementation) when calling the method (from caller).
ex,
public String createUser(String username, String password, SomeApiListener listener) {
someApi.do(config -> {
//code here with respect to someApi.
//somewhere here you are creating a TestListener ?,
//well... don't, and use the one passed from caller (listener)
});
}
Caller part will look like this:
public void method1(){
//..some code ...
createUser(username, password, new SomeApiListener(){
#Override
public void exception(Throwable cause) {
//handle exception...
}
#Override
public void success(Response response) {
//handle response ...
}
});
}
Note: you can still pass TetstListern, if you want, in that case you will have to have a physical class (local class) defined and instantiated, the anonymous-inner-class is somehow a shortcut for that, you don't create a local class, just pass it as an arg.
You can't, at least not in any simple way. I'd expect the documentation for your someApi to demonstrate some common use cases, with exception handling included. If you're combining different ways of programming ("normal" java & functional programming), you can get into tricky situations.
Based on the information you've given, a clumsy solution could look something like this (code obviously not fit for compilation):
public class MyClass implements SomeApiListener {
private Throwable e;
public void exception(Throwable cause) {
e = cause;
}
public void method1() {
createUser("foo", "bar");
if(e != null) {
// Exception was thrown, do something with it
}
}
}
However this is in no way a recommendation. It's clumsy, hacky and bad in every way. A better solution would involve not trying to send the exception back to method1, but instead to modify your code to work in the way that someApi expects.
It depends on your design on how to handle exceptions. Normally, if the method 2 is an utility method then throw the exception back to method 1 and let it handle the exception. Else, if method 2 understands the use case for which it is called then handle the exception there. There are no hard and fast rules, but keep the utility classes clean and send the exception back to the caller so that caller can handle it.
Related
I need to test the Exception but it gets the following error.
org.testng.TestException:
Method ContactIdentifierHelperTest.test()
[pri:0, instance:se.cambio.contactadministration.contact.helper.ContactIdentifierHelperTest#6d7b4f4c]
should have thrown an exception of type class SpiderException
Test method:
#Test(expectedExceptions = { SpiderException.class })
public void test() {
ContactData contactData = getContactData();
contactIdentifierHelper.getSpellId(contactData);
}
Method tested:
public String getSpellId(final ContactData contactData)
{
String s = null;
try
{
s = someMethod();
}
catch (SpiderException e)
{
e.printStackTrace();
}
return s;
}
Where have I gone wrong in this?
The expected behavior is that your method throws an Exception and your test fails, but it cannot never be successful (and this is correct), because you catch the exception in the body of your method.
In order to throw the exception you can simply have:
public String getSpellId(final ContactData contactData) throws SpiderException
{
return someMethod();
}
However, keep in mind that your test will be successful only if someMethod() effectively throws an exception!
Now, let me make a remark: this test does not have any sense: you are testing getSpellId but your buisiness logic is inside someMethod, and furthemore, getSpellId accept a parameter that is never used in the body ...
I suggest you change the way you think about this.
You need a repeatable, predictable way for your tested method to thrown an exception. One way to achieve that is via certain inputs.
Imagine your method looks something like this:
public String getSpellId(final ContactData contactData) throws SpiderException
{
if ( contactData == null ) throw new ArgumentException("input is null")
//some other code
}
this is something repeatable, you can always trigger the exception by passing null. You know how your code should behave, there is no uncertainty and you can test for this behaviour.
What you have however is another method call, which might fail, but you don't know how and why. This is a big no, when it comes to unit testing.
You might be better served by adding an exception test for your other method and not bother with this one.
What you really want to avoid is for your test to have too much knowledge of the code under test. You don't want to have to go through who knows how many layers in order to achieve what you want, because this leaves you with brittle tests which will need to change every time a code change happens.
So, change the way you think about the code and aim to make it testable.
Also, if you want to test for an exception, you must make sure you don't catch that exception as this will hide the actual thing.
I am looking for a design pattern to handle Exception instances received as method arguments.
To put some context into the question, I am using GWT and have various asynchronous handlers that usually come in a form similar to:
public interface AsyncCallback<T> {
void onFailure(Throwable caught);
void onSuccess(T result);
}
So, the onFailure method receives a Throwable instance that I need to handle.
Now, I have a number of exceptions I can receive in this method, for example
ConstraintViolationException
TimeoutException
NoSuchElementException
In my handling code I could of course write the following:
void handleException(final Exception e) {
if(e instanceof TimeoutException) {
handleTimeout();
} else if (e instanceof NoSuchElementException) {
handleInvalidElement();
} else {
stopAndCatchFire();
}
}
But to my eye, that looks very ugly. The large if..else if chain combined with heavy usage of instanceof seems like something that should be avoided.
I thought that maybe I could use the try...catch construct to handle the Exception using something like the following:
void handleException(final Exception e) {
try {
throw e;
} catch (TimeoutException te) {
handleTimeout();
} catch (NoSuchElementException nsee) {
handleInvalidElement();
} catch (Exception ex) {
stopAndCatchFire();
}
}
But this seems like an abuse somehow. Do you see any downsides to the second approach or another approach I could go with to avoid the first case?
Could you not have a dictionary of exceptionHandlers keyed by the type of exception they handle, then when you get a exception you look in the dictionary for the handler for the exception type. If there is one, then pass the exception to the handler, if there isn't then use the default handler.
So your handler becomes something like this:
void handleException(final Exception e) {
if (handlers.containsKey(e.getType())
{
handlers[e.getType()].handle(e);
}
else
{
defaultHandler.handle(e);
}
}
My Java is a bit rusty, so the example is c-sharpy but should be simple enough to translate (though I remembered not to capitalise the first letter of everything :))
This approach should have the advantage that you can add new handlers simply.
It will however suffer if you have the same handler for sub types, as you will have to register each subtype explicitly.
To get around this issue simply make each handler responsible for making the decision about whether it can handle an exception:
public interface ExceptionHandler
{
bool canHandle(Exception e);
void handle(Exception e)
}
then just put the handlers in a list an iterate asking each one if it can handle the current exception and when you find one that can, get it to handle it.
But to my eye, that looks very ugly. The large if..else if chain combined with heavy usage of instanceof seems like something that should be avoided.
I don't agree. I think this snippet of code is using both language constructs exactly how they were intended. If the code becomes unmanageable (too many clauses) then you should question the approach to error handling generally, rather than the specifics of this method. At that stage you might want to consider AOP.
The second approach on the other hand is horrible ;)
You can make it more elegant just by handling the if statements inside the exceptions inside the function.
void handleException(Exception e){
handleOne(e)
handleTwo(e)
...
}
It looks prettier. Of course, every function is always called, but its first line is just an if statement. There are variations - e.g. make your handle functions guava function objects, put them in a list, and iterate through them until you get the first one that returns "true". Something like:
public class handlerOne implements Function<Exception, Boolean> {
Boolean apply(Exception input) {
return handlerOne();
}
}
Then your handle function can be something like:
void handleException(Exception e){
list<Function<Exception, Boolean> list = Object.getHandlers(); //store your handlers somewhere
for(Function<Exception, Boolean> f : list){
if(f.apply(e)){
break
}
}
}
That way you insure only one handler which works is called, and you can control the order by changing the order of the list, since the list iterator will return them in order.
Control flow on exceptions should be avoided, and should certainly not be in the onFailure. the onFailure method should be as simple as possible.
Modify whatever code is run asynchronously to handle the exception cases there. The ElementNotFound-exception could be handled by just checking if an element exists prior to doing anything. Timeout-exception could be handled by surrounding the code that can timeout (calling a webservice or something)?) by a try .. catch block.
Then extend the result-type T to contain extra information that a timeout occurred or an element is not found - if needed.
I have the folowing constructor...
#Inject
public EditorPresenter(final EventBus eventBus, final MyView view, final Provider<DataProvider> provider) {
DataProvider provider = provider.get();
provider.getInitData().fire(new Receiver<List<DataElement>>() {
#Override
public void onSuccess(List<DataElement> response) {
LOG.info("seting feed types to {}", response);
EditorPresenter.this.data = response;
}
});
}
This constructor sets the class field data to the values returned in the request factory call.
The problem is this data requires a call to the server and is thus asynchronous.
And this field needs to be set when the constructor returns as other objects/beans depend on it (I'm having subsequent errors that depend on data being initalised).
What is the most efficient and light weight way of handling this scenario with Gin?
I'm hoping that there is something built into GIN that handles this scenario gracefully.
GQuery Promise solves this kind of situations:
Something like:
public void yourMethod(....) {
....
getDataFromServer(provider).then(processData)
.done(new Function() { public void f(){
continueYourFlow();
}})
.fail(new Function() { public void f(){
handleError();
}});
}
protected Promise getDataFromServer(final Provider<DataProvider> provider) {
return new PromiseRF(provider.getInitData());
}
Function proccessData = new Function() { public void f() {
List<DataElement> data = arguments(0);
//do something with your data
}};
should work. If not, just ask!
There is something wrong in your approach. You shouldn't hold all your application waiting for server.
If I understand, some data from server is required before client is initialized. Maybe you should put them in your host page? Or move initialization of presenters to other methods and execute these methods by events.
It might be best to not initialize the rest of your app yet. I'm not sure how your initialization is laid out, but I would not initialize anymore after you inject the instance of your EditorPresenter class.
When your onSuccess call gets triggered, fire an event or call a method that picks up where you would have left off. If you think it will be a while you could throw up a wait screen or some such.
I have some code
service.doAction(request, Callback<Response> callback);
How can I using Mockito grab the callback object, and call callback.reply(x)
You want to set up an Answer object that does that. Have a look at the Mockito documentation, at
https://static.javadoc.io/org.mockito/mockito-core/2.8.47/org/mockito/Mockito.html#answer_stubs
You might write something like
when(mockService.doAction(any(Request.class), any(Callback.class))).thenAnswer(
new Answer<Object>() {
Object answer(InvocationOnMock invocation) {
((Callback<Response>) invocation.getArguments()[1]).reply(x);
return null;
}
});
(replacing x with whatever it ought to be, of course)
Consider using an ArgumentCaptor, which in any case is a closer match to "grab[bing] the callback object".
/**
* Captor for Response callbacks. Populated by MockitoAnnotations.initMocks().
* You can also use ArgumentCaptor.forClass(Callback.class) but you'd have to
* cast it due to the type parameter.
*/
#Captor ArgumentCaptor<Callback<Response>> callbackCaptor;
#Test public void testDoAction() {
// Cause service.doAction to be called
// Now call callback. ArgumentCaptor.capture() works like a matcher.
verify(service).doAction(eq(request), callbackCaptor.capture());
assertTrue(/* some assertion about the state before the callback is called */);
// Once you're satisfied, trigger the reply on callbackCaptor.getValue().
callbackCaptor.getValue().reply(x);
assertTrue(/* some assertion about the state after the callback is called */);
}
While an Answer is a good idea when the callback needs to return immediately (read: synchronously), it also introduces the overhead of creating an anonymous inner class, and unsafely casting the elements from invocation.getArguments()[n] to the data type you want. It also requires you to make any assertions about the pre-callback state of the system from WITHIN the Answer, which means that your Answer may grow in size and scope.
Instead, treat your callback asynchronously: Capture the Callback object passed to your service using an ArgumentCaptor. Now you can make all of your assertions at the test method level and call reply when you choose. This is of particular use if your service is responsible for multiple simultaneous callbacks, because you have more control over the order in which the callbacks return.
If you have a method like:
public void registerListener(final IListener listener) {
container.registerListener(new IListener() {
#Override
public void beforeCompletion() {
}
#Override
public void afterCompletion(boolean succeeded) {
listener.afterCompletion(succeeded);
}
});
}
Then following way you can mock the above method easily:
#Mock private IListener listener;
#Test
public void test_registerListener() {
target.registerListener(listener);
ArgumentCaptor<IListener> listenerCaptor =
ArgumentCaptor.forClass(IListener.class);
verify(container).registerListener(listenerCaptor.capture());
listenerCaptor.getValue().afterCompletion(true);
verify(listener).afterCompletion(true);
}
I hope this might help someone, as I had spend lot of time in figuring out this solution.
when(service.doAction(any(Request.class), any(Callback.class))).thenAnswer(
new Answer() {
Object answer(InvocationOnMock invocation) {
Callback<Response> callback =
(Callback<Response>) invocation.getArguments()[1];
callback.reply(/*response*/);
}
});
I just can't figure out how to remove listener when I have some event executed. I have some leaking issue using websockets, and this can probaly fix it.
final WebSocket w = asyncHttpClient.prepareGet(url)
.execute(new WebSocketUpgradeHandler.Builder().build())
.get();
w.addWebSocketListener(new WebSocketTextListener() {
public void onMessage(String message) {
listener.onMessage(responseMessage);
// Here is the place I want to do my w.removeWebSocketListener(l);
}
#Override
public void onFragment(String s, boolean b) {
}
public void onOpen(WebSocket websocket) {
}
#Override
public void onClose(WebSocket webSocket) {
}
#Override
public void onError(Throwable throwable) {
}
});
The problem is when I create WebSocketTextListener lis = new .... and passing in there is something like one object need other object and other object is dependent on this, and I'm still now allowed to do what I want.
Looks like it is something simple, but can't figure out.
Normally event listeners can be removed with a removeXXXListener method. But it requires that you provide the exact same event listener instance as parameter. You can store the event listener and later remove it using the same reference. But since you, in the onMessage message already are inside the scope of the event listener, using this should work.
Try something like
listener.onMessage(responseMessage);
// Here is the place I want to do my w.removeWebSocketListener(l);
w.removeWebSocketListener(this);
Using "this" in anonumous inner class is the way to solve problem. But, it is muck better to refactor code, to avoid using anonumous classes, for testability and better understanding.