Let's say I have an interceptor that looks smth like this:
public class AuthorizationInterceptor {
Logger log = Logger.getLogger(getClass().getName());
#AroundInvoke
private Object authorize(InvocationContext ic) throws Exception{
// ... some other logic for authorization
if (!allowedMethods.contains(ic.getMethod().getName())){
log.info("Authorization failed. Preparing to throw exception");
throw new AuthException("Authorization failed for method " +
ic.getMethod().getName());
}
return ic.proceed();
}
}
which is applied to different methods from my EJBs.
I would normally expect the exception throed to be passed to the invoking client, like all normal EJB exceptions.
Apparently this doesn't happen if I throw it from an Interceptor... It's not even logged on the server; like it's never thrown although it is - the return statement is never executed.
What am I doing wrong?
I'm using GF 3.0.1
After searching a bit for this issue, I found this SO post which was answered a few minutes ago. Quote:
I don't think there is a correct way
to do that. Methods should throw only
the exceptions they declared, and an
interceptor shouldn't add a new one.
My personal case got fixed by adding
an error code to our default exception
which is thrown by all methods.
Question author is the same person who answered and accepted this answer, so I guess he was trying to solve the same issue as you and came to conclusion that it cannot be done.
Here are a couple of things to try:
1. Check that the authorize(...) method is called.
2. Try making the authorize(...) method public instead of private.
3. Check that the EJB has an annotation like this:
#Interceptors(AuthorizationInterceptor.class)
Related
Quick question regarding Java Micrometer with #Counted and #ExceptionHandler please.
I have a very straightforward #ExceptionHandler:
#ExceptionHandler
#Counted(value = "MY_EXCEPTION", description = "SOME_DESCRIPTION")
public Mono<ResponseEntity<String>> myCoolExceptionHandler(final RuntimeException runtimeException) {
System.err.println("an exception!" + runtimeException);
return Mono.just("bad");
}
I think this combination is quite interesting, as it gives visibility on exception happening. We can build dashboard, alerts, etc, quite cool.
Unfortunately, when I looked at the metric generated, it was something like:
# HELP MY_EXCEPTION_total SOME_DESCRIPTION
# TYPE MY_EXCEPTION_total counter
MY_EXCEPTION_total{class="package.MyController",exception="none",method="myCoolExceptionHandler",result="success",} 3.0
I am quite puzzled on exception="none" and result="success"
May I ask how those values got into the metric in the first place?
Also, how to change them into something more meaningful, such as the exception class for instance?
Thank you!
The annotated method itself does not throw an exception and always completes normally. Therefore, the intercepting code installed by the annotation will never record an exception (exception=none) and the outcome will always be good (result=success). Only exceptions thrown from within the annotated method will be recorded as an error outcome.
You can always manually record metrics by injecting the MetricRegistry and then registering a metric with the appropriate name and tags.
Suppose I've got an endpoint in Dropwizard, say
#GET
public Response foo() { throw new NullPointerException(); }
When I hit this endpoint it logs the exception and everything, which is great! I love it. What I love less is that it returns a big status object to the user with status: ERROR (which is fine) as well as a gigantic stack trace, which I'm less excited about.
Obviously it's best to catch and deal with exceptions on my own, but from time to time they're going to slip through. Writing a try catch block around the entire resource every time is fine, but (a) it's cumbersome, and (b) I always prefer automated solutions to "you have to remember" solutions.
So what I would like is something that does the following:
Logs the stack trace (I use slf4j but I assume it would work for whatever)
Returns a general purpose error response, which does not expose potentially privileged information about my server!
I feel like there must be a built-in way to do this -- it already handles exceptions in a relatively nice way -- but searching the docs hasn't turned up anything. Is there a good solution for this?
As alluded to by reek in the comments, the answer is an ExceptionMapper. You'll need a class like this:
#Provider
public class RuntimeExceptionMapper implements ExceptionMapper<RuntimeException> {
#Override
public Response toResponse(RuntimeException runtime) {
// ...
}
}
You can do whatever logging or etc. you like in the toResponse method, and the return value is what is actually sent up to the requester. This way you have complete control, and should set up sane defaults -- remember this is for errors that slip through, not for errors you actually expect to see! This is also a good time to set up different behaviors depending on what kind of exceptions you're getting.
To actually make this do anything, simply insert the following line (or similar) in the run method of your main dropwizard application:
environment.jersey().register(new RuntimeExceptionMapper());
where environment is the Environment parameter to the Application's run method. Now when you have an uncaught RuntimeException somewhere, this will trigger, rather than whatever dropwizard was doing before.
NB: this is still not an excuse not to catch and deal with your exceptions carefully!
Add the following to your yaml file. Note that it will remove all the default exception mappers that dropwizard adds.
server:
registerDefaultExceptionMappers: false
Write a custom exception mapper as below:
public class CustomExceptionMapper implements ExceptionMapper<RuntimeException> {
#Override
public Response toResponse(RuntimeException runtime) {
// ...
}
}
Then register the exception mapper in jersey:
environment.jersey().register(new CustomExceptionMapper());
Already mentioned this under the comments, but then thought I would give it a try with a use case.
Would suggest you to start differentiating the Exception that you would be throwing. Use custom exception for the failures you know and throw those with pretty logging. At the same RuntimeException should actually be fixed. Anyhow if you don't want to display stack trace to the end user you can probably catch a generic exception, log the details and customize the Response and entity accordingly.
You can define a
public class ErrorResponse {
private int code;
private String message;
public ErrorResponse() {
}
public ErrorResponse(int code, String message) {
this.code = code;
this.message = message;
}
... setters and getters
}
and then within you resource code you can modify the method as -
#GET
public Response foo() {
try {
...
return Response.status(HttpStatus.SC_OK).entity(response).build();
} catch (CustomBadRequestException ce) {
log.error(ce.printStackTrace());
return Response.status(HttpStatus.SC_BAD_REQUEST).entity(new ErrorResponse(HttpStatus.SC_BAD_REQUEST, ce.getMessage())).build();
} catch (Exception e) {
log.error(e.printStackTrace(e));
return Response.status(HttpStatus.SC_INTERNAL_SERVER_ERROR).entity(new ErrorResponse(HttpStatus.SC_INTERNAL_SERVER_ERROR, e.getMessage())).build();
}
}
This article details Checked and Unchecked Exceptions implementation for Jersey with customized ExceptionMapper:
https://www.codepedia.org/ama/error-handling-in-rest-api-with-jersey/
Official Dropwizard documentation also covers a simpler approach, just catching using WebApplicationException:
#GET
#Path("/{collection}")
public Saying reduceCols(#PathParam("collection") String collection) {
if (!collectionMap.containsKey(collection)) {
final String msg = String.format("Collection %s does not exist", collection);
throw new WebApplicationException(msg, Status.NOT_FOUND)
}
// ...
}
https://www.dropwizard.io/en/stable/manual/core.html#responses
It worked for me by simply registering the custom exception mapper created in the run method of the main class.
environment.jersey().register(new CustomExceptionMapper());
where CustomExceptionMapper can implement ExceptionMapper class like this
public class CustomExceptionMapperimplements ExceptionMapper<Exception>
I am experiencing a certain bug in JUnit/JMock. I am trying to mock a couple of objects and then assert that all expectations is satisfied. I am running a simple test such as :
#Test
public void sellingPutOptionProductDoesNotCauseDisclosure() throws PositionVerificationException, DataLoadException, MissingPriceException {
final OptionProduct optionProduct = setupOptionProduct();
context.assertIsSatisfied();
}
private OptionProduct setupOptionProduct() {
final Option optionProduct = context.mock(Option.class);
context.checking(new Expectations() {
{
oneOf(optionProduct).getUnderlyingProduct();
will(returnValue(new Object()));
}
});
return optionProduct;
}
The Option is an object and I am using Mockery like this:
context = new Mockery() {
{
setImposteriser(ClassImposteriser.INSTANCE);
}
};
If I run the above test I am gettiing Test passed, where JVM does not terminate and the last print out in console is:
Exception in thread "main"
ANy ideas what might be causing this?
I'm a little late to the party, but I just had a similar problem and was able to track down the cause.
Normally, when a method is called that is not part of the expectations, JMock builds the log telling you what was expected that was not found. In my case, it tried to create that log message after encountering an unexpected call. The act of creating the log message threw an exception, which got JMock all confused and it reported that the test passed, when it had actually failed.
In my case, the reason that the exception was thrown was that one of the parameters being passed to the "unexpected" function call was an instance of a class. That class was initialized, in part, with mocked objects. When JMock was trying to build the error message to tell me about the unexpected invocation, it needed to describe the parameter. Usually it will say something like unexpected invocation: myobject.myMethod(param1,param2).
Because param1, in my case, contained member variables that were mock objects, and the param1 class did not define toString(), the default, Object.toString() was used.
Object.toString() is defined as: return getClass().getName() + "#" + Integer.toHexString(hashCode());
My implementation of hashcode for param1 was using some of those mocked objects. Those calls on the mocked objects to calculate the hashcode were 'unexpected' invocations themselves, leading JMock to throw an exception when trying to describe the test failure to me.
Unfortunately, instead of recognizing this condition and still reporting as much of the failure as it could, JMock seemed to give up altogether and report the test as passing and offhandedly mention Exception in thread "main."
To see if this is happening to you, I recommend you check the parameters involved in the offending function calls. If any of them are classes, not interfaces, you should see if their use of equals / hashcode / toString use any suspicious calls to member variables that may not be playing nice with how your scenario is being mocked.
I'm pondering on exception handling and unit tests best practices because we're trying to get some code best practices in place.
A previous article regarding best practices, found on our company wiki, stated "Do not use try/catch, but use Junit4 #Test(expect=MyException.class)", without further information. I'm not convinced.
Many of our custom exception have an Enum in order to identify the failure cause.
As a result, I would rather see a test like :
#Test
public void testDoSomethingFailsBecauseZzz() {
try{
doSomething();
} catch(OurCustomException e){
assertEquals("Omg it failed, but not like we planned", FailureEnum.ZZZ, e.getFailure());
}
}
than :
#Test(expected = OurCustomException.class)
public void testDoSomethingFailsBecauseZzz() {
doSomething();
}
when doSomethig() looks like :
public void doSomething throws OurCustomException {
if(Aaa) {
throw OurCustomException(FailureEnum.AAA);
}
if(Zzz) {
throw OurCustomException(FailureEnum.ZZZ);
}
// ...
}
On a side note, I am more than convinced that on some cases #Test(expected=blabla.class) IS the best choice (for example when the exception is precise and there can be no doubt about what's causing it).
Am I missing something here or should I push the use of try/catch when necessary ?
It sounds like your enum is being used as an alternative to an exception hierarchy? Perhaps if you had an exception hierarchy the #Test(expected=XYZ.class) would become more useful?
If you simply want to check that an exception of a certain type was thrown, use the annotation's expected property.
If you want to check properties of the thrown exception (e.g. the message, or a custom member value), catch it in the test and make assertions.
In your case, it seems like you want the latter (to assert that the exception has a certain FailureEnum value); there's nothing wrong with using the try/catch.
The generalization that you should "not use try/catch" (interpreted as "never") is bunk.
Jeff is right though; the organization of your exception hierarchy is suspect. However, you seem to recognize this. :)
If you want to check the raw exception type, then the expected method is appropriate. Otherwise, if you need to test something about the exception (and regardless of the enum weirdness testing the message content is common) you can do the try catch, but that is a bit old-school. The new JUnit way to do it is with a MethodRule. The one that comes in the API (ExpectedException) is about testing the message specifically, but you can easily look at the code and adapt that implementation to check for failure enums.
In your special case, you want to test (1) if the expected exception type is thrown and (2) if the error number is correct, because the method can thrown the same exception with different types.
This requires an inspection of the exception object. But, you can stick to the recommendation and verify that the right exception has been thrown:
#Test(expected = OurCustomException.class)
public void testDoSomethingFailsBecauseZzz() {
try {
doSomething();
} catch (OurCustomException e) {
if (e.getFailureEnum.equals(FailureEnum.ZZZ)) // use *your* method here
throw e;
fail("Catched OurCostomException with unexpected failure number: "
+ e.getFailureEnum().getValue()); // again: your enum method here
}
}
This pattern will eat the unexpected exception and make the test fail.
Edit
Changed it because I missed the obvious: we can make a test case fail and capture a message. So now: the test passes, if the expected exception with the expected error code is thrown. If the test fails because we got an unexpected error, then we can read the error code.
I came across this when searching how to handle exceptions.
As #Yishai mentioned, the preferred way to expect exceptions is using JUnit rules and ExpectedException.
When using #Test(expected=SomeException.class) a test method will pass if the exception is thrown anywhere in the method.
When you use ExpectedException:
#Test
public void testException()
{
// If SomeException is thrown here, the test will fail.
expectedException.expect(SomeException.class);
// If SomeException is thrown here, the test will pass.
}
You can also test:
an expected message: ExpectedException.expectMessage();
an expected cause: expectedException.expectCause().
As a side note: I don't think using enums for exception messages/causes is good practice. (Please correct me if I'm wrong.)
I made catch-exception because I was facing the same problem as you did, Stph.
With catch-exception your code could look like this:
#Test
public void testDoSomethingFailsBecauseZzz() {
verifyException(myObj, OurCustomException.class).doSomething();
assertEquals("Omg it failed, but not like we planned", FailureEnum.ZZZ,
((OurCustomException)caughtException()).getFailure() ;
}
I've got a unit test for a Seam component that should fail if a value isn't provided in the context before the backing bean is created. I've been able to test this manually but would like to cover this scenario with a unit test.
I'm basically getting a org.jboss.seam.InstantiationException caused by a java.lang.IllegalArgumentException when Seam tries to create the backing bean. This is good and is what I'd expect to happen. The problem is that when I write the unit test, I can neither put a try/catch around the new FacesRequest(..) {}.run(); or use the expectedExceptions annotation. In both cases, the exception is not caught and causes the test to fail. I assume this is because of Seam's exception filter but I don't know enough about the filter to know what the correct pattern to test this..
My code with the annotation looks something like this:
// also tried IlligalArgumentException here
#Test( enabled = true, expectedExceptions = InstantiationException.class )
public void noDataTest() throws Exception
{
login( USERNAME );
// the stack trace says that the test fails on the next line.
// this is expected.
new FacesRequest( "/blah/blah/show.xhtml" ) {
#Override
protected void updateModelValues() {
}
#Override
protected void invokeApplication()
{
// we should never get here
// i'll put an failure here eventually
}
}.run();
}
I found the answer. Hopefully this helps someone else who was banging their head against the wall..
I was looking for a specific Exception but Seam was catching that Exception, asserting that an error had occurred, and then throwing a java.lang.AssertionError (java.lang.Error, not java.lang.Exception). Catching the correct Throwable and using the correct type in the annotation now work..
looks to me that your test case is expecting a empty no-arg constructor in backing bean whic is probably missing