We Keep Coding

Spring Boot Application - Is it considered bad practice to throw EntityExists - or EntityNotFoundException from Service to Controller?

My understanding of these exceptions is if an object in the database that you are looking for doesn't exist or exists these gets thrown? But is it ok for myself to use when I want to handle different cases in MyServiceClass.
Is it bad practice to throw these exceptions or should I create my own Exceptions for let's say if a user dont exist in the database?
How does it work in a real production?
Thanks in advance!

You should only implement a custom exception if it provides a benefit compared to Java's standard exceptions. The class name of your exception should end with Exception.
But it’s sometimes better to catch a standard exception and to wrap it into a custom one. A typical example for such an exception is an application or framework specific business exception. That allows you to add additional information and you can also implement a special handling for your exception class.
When you do that, make sure to set the original exception as the cause. The Exception class provides specific constructor methods that accept a Throwable as a parameter. Otherwise, you lose the stack trace and message of the original exception which will make it difficult to analyze the exceptional event that caused your exception.
public void wrapException(String input) throws MyBusinessException {
try {
// do something
} catch (NumberFormatException e) {
throw new MyBusinessException("A message that describes the error.", e);
}
}
Try not to create new custom exceptions if they do not have useful information for client code.
And if you make a custom exception be sure to:
Document the Exceptions You Specify
Throw Exceptions With Descriptive Messages
Catch the Most Specific Exception First
Don’t Log and Throw

Java : Received Exception VS Catched exception

I need to implement Exception management component, in Java.
Having this class :
public class Foo {
void connect(){
// some instructions here...
}
}
The specification document that I have it uses such expressions :
1. A_Exception can be received.
2. B_Exception can be catched as C_Exception<B_Exception> .
Edit :
What is the difference between a catched exception and a received exception? Some sample codes would be so helpful.
Thank you a lot!

Exception what will going to be handle is depends on the context. Importantly Checked Exception can be handle. You have to provide the context for this case. Normally NullPointerException not going to handle and will code the way not occur NPE.

JUnit4 #Test(expected=MyException.class) VS try/catch

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() ;
}

throw checked Exceptions from mocks with Mockito

I'm trying to have one of my mocked objects throw a checked Exception when a particular method is called. I'm trying the following.
#Test(expectedExceptions = SomeException.class)
public void throwCheckedException() {
List<String> list = mock(List.class);
when(list.get(0)).thenThrow(new SomeException());
String test = list.get(0);
}
public class SomeException extends Exception {
}
However, that produces the following error.
org.testng.TestException:
Expected exception com.testing.MockitoCheckedExceptions$SomeException but got org.mockito.exceptions.base.MockitoException:
Checked exception is invalid for this method!
Invalid: com.testing.MockitoCheckedExceptions$SomeException
Looking at the Mockito documentation, they only use RuntimeException, is it not possible to throw checked Exceptions from a mock object with Mockito?

Check the Java API for List.
The get(int index) method is declared to throw only the IndexOutOfBoundException which extends RuntimeException.
You are trying to tell Mockito to throw an exception SomeException() that is not valid to be thrown by that particular method call.
To clarify further.
The List interface does not provide for a checked Exception to be thrown from the get(int index) method and that is why Mockito is failing.
When you create the mocked List, Mockito will use the definition of List.class to creates its mock.
The behavior you are specifying with the when(list.get(0)).thenThrow(new SomeException()) doesn't match the method signature in List API, because get(int index) method does not throw SomeException() so Mockito fails.
If you really want to do this, then have Mockito throw a new RuntimeException() or even better throw a new ArrayIndexOutOfBoundsException() since the API specifies that that is the only valid Exception to be thrown.

A workaround is to use a willAnswer() method.
For example the following works (and doesn't throw a MockitoException but actually throws a checked Exception as required here) using BDDMockito:
given(someObj.someMethod(stringArg1)).willAnswer( invocation -> { throw new Exception("abc msg"); });
The equivalent for plain Mockito would to use the doAnswer method

There is the solution with Kotlin :
given(myObject.myCall()).willAnswer {
throw IOException("Ooops")
}
Where given comes from
import org.mockito.BDDMockito.given

Note that in general, Mockito does allow throwing checked exceptions so long as the exception is declared in the message signature. For instance, given
class BarException extends Exception {
// this is a checked exception
}
interface Foo {
Bar frob() throws BarException
}
it's legal to write:
Foo foo = mock(Foo.class);
when(foo.frob()).thenThrow(BarException.class)
However, if you throw a checked exception not declared in the method signature, e.g.
class QuxException extends Exception {
// a different checked exception
}
Foo foo = mock(Foo.class);
when(foo.frob()).thenThrow(QuxException.class)
Mockito will fail at runtime with the somewhat misleading, generic message:
Checked exception is invalid for this method!
Invalid: QuxException
This may lead you to believe that checked exceptions in general are unsupported, but in fact Mockito is only trying to tell you that this checked exception isn't valid for this method.

This works for me in Kotlin:
when(list.get(0)).thenThrow(new ArrayIndexOutOfBoundsException());
Note : Throw any defined exception other than Exception()

Seam unit testing with exception filter and expectedExceptions annotation

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