Develop Reference

How to handle a NullPointerException?

I'm quite new to Java and stuck with handling NullPointerException -
I have a method as follows in order to build a HTTP Request as follows -
``
public static Http.Request Requester(String pingpoint) {
final String endPoint = URLBuilder.constructPing(pingpoint);
return BackendHttpRequest
.GET()
.pingURL(endPoint)
.build();
}
``
I don't want users to provide -
"~" - A tilde as an input
null - No null input
If user provides either of the above inputs we need to handle them as a NullPointerException.
What I'm trying to do -
``
public static Http.Request Requester(String pingpoint) {
try {
if(pingpoint != && pingpoint.equals("~")) {
final String endPoint = URLBuilder.constructPing(pingpoint);
return BackendHttpRequest
.GET()
.pingURL(endPoint)
.build();
}
} catch(NullPointerException e) {
System.out.println("NullPointerException thrown!");
}
}
``
However, Intellij is point to an error at the very end of curly braces to return a value of HTTP Request. I'm not sure what to return.
Any teachings on this will be really helpful! Thanks in advance.

probably you want to throw exception, like this:
public static Http.Request Requester(String pingpoint) {
if (pingpoint == null || pingpoint.equals("~"))
throw new NullPointerException();
final String endPoint = URLBuilder.constructPing(pingpoint);
return BackendHttpRequest.GET().pingURL(endPoint).build();
}

Entity from Optional Object (Java 8)

I am having some issue while trying to pull an entity out of an ArrayList that holds and Optional. When I do a breakpoint I get the return below the code. I know I am close but lack the knowledge on how to pull the GrandClientDataCore#9463 out of the data being returned to me.
Edited to add the previous line before the for loop.
Error occured: java.util.Optional cannot be cast to net.glmhc.dmhwebservices.entities.GrandClientDataCores.
List<GrandClientDataCores> grandClientDataCoresList = getGrandClientDataCoreList(submitMode, grandClientDataCoreId);
for (GrandClientDataCores grandClientDataCores : grandClientDataCoresList) {
CDCPAErrors request = new CDCPAErrors();
request.setI(this.service.getRequestInfo(grandClientDataCores, submitMode, staff));
logToFile(outDir, String.format("req_%s.xml", new Object[] {grandClientDataCores}), request);
CDCPAErrorsResponse response = (CDCPAErrorsResponse)
getWebServiceTemplate().marshalSendAndReceive(getWebServiceUri(), request,
(WebServiceMessageCallback) new SoapActionCallback("http://tempuri.org/CDCPAErrors"));
logToFile(outDir, String.format("res_%s.xml", new Object[] {grandClientDataCoreId}), response);
DmhServicesCdcResponse responseObj = getResponse(submitMode, response);
this.service.saveResponse(grandClientDataCores, submitMode, responseObj, staff);
responses.add(responseObj);
}
This is the getGrandClientDataCoreList
protected List<GrandClientDataCores> getGrandClientDataCoreList(SubmitMode submitMode, String grandClientDataCore) throws Exception {
List<GrandClientDataCores> grandClientDataCoresList;
try {
grandClientDataCoresList = (List<GrandClientDataCores>) this.service.getGrandClientDataCoreList(submitMode, grandClientDataCore);
} catch ( Exception ex) {
throw new Exception(ex);
}
if (grandClientDataCore == null || grandClientDataCore.isEmpty()) {
throw new NoDataException("No CDC record to validate.");
}
return grandClientDataCoresList;
}

You have to invoke get() on the optional to retrieve its value. You cannot just cast Optional<T> to something else. According to the debug image, the declaration of grandClientDataCoresList looked like this:
List<Optional<GrandClientDataCores>> grandClientDataCoresList ...
Therefore you need something like this:
for (Optional<GrandClientDataCores> gcdcOpt: grandClientDataCoresList) {
GrandClientDataCores gcdc = gcdcOpt.get();
....
values in grandClientDataCores are of type Optional<GrandClientDataCores>.
Your actual error is here:
protected List<GrandClientDataCores> getGrandClientDataCoreList(SubmitMode submitMode, String grandClientDataCore) throws Exception {
List<GrandClientDataCores> grandClientDataCoresList;
try {
grandClientDataCoresList = (List<GrandClientDataCores>) this.service.getGrandClientDataCoreList(submitMode, grandClientDataCore);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This cast is invalid
} catch ( Exception ex) {
throw new Exception(ex);
}
if (grandClientDataCore == null || grandClientDataCore.isEmpty()) {
throw new NoDataException("No CDC record to validate.");
}
return grandClientDataCoresList;
}
You will find that the actual type returned by this.service.getGrandClientDataCoreList is List<Optional<GrandClientDataCores>> so you must update your code accordingly, in a number of places. For starters...
protected List<Optional<GrandClientDataCores>> getGrandClientDataCoreList(SubmitMode submitMode, String grandClientDataCore) throws Exception {
List<Optional<GrandClientDataCores>> grandClientDataCoresList;
try {
grandClientDataCoresList = this.service.getGrandClientDataCoreList(submitMode, grandClientDataCore);
} catch ( Exception ex) {
throw new Exception(ex);
}
if (grandClientDataCore == null || grandClientDataCore.isEmpty()) {
throw new NoDataException("No CDC record to validate.");
}
return grandClientDataCoresList;
}
and everywhere that you invoke this method.

use the "get()" function of Optional, which will retrieve the object itself.
pay attention it will throw an exception if no object was populated into this Optional.

GrandClientDataCores values in List are wrapped with Optional, so you have to check if value present:
grandClientDataCores.isPresent()
and if it is then just get it:
grandClientDataCores.get();
Alternatively, you can do something like that:
grandClientDataCores.orElse(new GrandClientDataCores())
And I recommend to read this

Handle exception after reaching max attempts in resilience4j-retry using Spring Boot

I have a scenario I want to log each retry attempt and when the last one fails (i.e. maxAttempts reached) a exception is thrown and let's say an entry to a database is created.
I try to achieve this using Resilience4j-retry with Spring Boot, therefore I use application.yml and annotations.
#Retry(name = "default", fallbackMethod="fallback")
#CircuitBreaker(name = "default", fallbackMethod="fallback")
public ResponseEntity<List<Person>> person() {
return restTemplate.exchange(...); // let's say this always throws 500
}
The fallback logs the cause of the exception into an application log.
public ResponseEntity<?> fallback(Exception e) {
var status = HttpStatus.INTERNAL_SERVER_ERROR;
var cause = "Something unknown";
if (e instanceof ResourceAccessException) {
var resourceAccessException = (ResourceAccessException) e;
if (e.getCause() instanceof ConnectTimeoutException) {
cause = "Connection timeout";
}
if (e.getCause() instanceof SocketTimeoutException) {
cause = "Read timeout";
}
} else if (e instanceof HttpServerErrorException) {
var httpServerErrorException = (HttpServerErrorException) e;
cause = "Server error";
} else if (e instanceof HttpClientErrorException) {
var httpClientErrorException = (HttpClientErrorException) e;
cause = "Client error";
} else if (e instanceof CallNotPermittedException) {
var callNotPermittedException = (CallNotPermittedException) e;
cause = "Open circuit breaker";
}
var message = String.format("%s caused fallback, caught exception %s",
cause, e.getMessage());
log.error(message); // application log entry
throw new MyRestException (message, e);
}
When I call this method person() the retry happens as maxAttempt configured. I expect my custom runtime MyRestException is caught on each retry and thrown on the last one (when maxAttempt is reached), so I wrap the call in the try-catch.
public List<Person> person() {
try {
return myRestService.person().getBody();
} catch (MyRestException ex) {
log.error("Here I am ready to log the issue into the database");
throw new ex;
}
}
Unfortunatelly, the retry seems to be ignored as the fallback encounters and rethrows the exception that is immediatelly caught with my try-catch instead of the Resilience4j-retry mechanism.
How to achieve the behavior when the maxAttempts is hit? Is there a way to define a specific fallback method for such case?

Why don't you catch and map exceptions to MyRestException inside of your Service methods, e.g. myRestService.person()?
It makes your configuration even simpler, because you only have to add MyRestException to the configuration of your RetryConfig and CircuitBreakerConfig.
Spring RestTemplate also has mechanisms to register a custom ResponseErrorHandler, if you don't want to add the boilerplate code to every Service method. -> https://www.baeldung.com/spring-rest-template-error-handling
I would not map CallNotPermittedException to MyRestException. You don't want to retry when the CircuitBreaker is open. Add CallNotPermittedException to the list of ignored exceptions in your RetryConfig.
I think you don't need the fallback mechanism at all. I thing mapping an exception to another exception is not a "fallback".

Java, what if I want to return different types from function?

public WHATTOWRITEHERE test()
{
try
{
transaction.begin();
code which may trigger exception
transaction.commit();
return true;
}
catch (javax.script.ScriptException ex)
{
transaction.rollback();
return ex.getMessage();
}
}
the code above intend to do something, if its OK then return true if not (error happened), this error message string should be returned. It do possible with Php but not with Java
EDIT: expection cant go outside, it has to be handled right here.

You can't return multiple types but you can redesign so you don't have to. Some possibilities:
Don't return an error message. Throw or rethrow an exception instead and let the caller handle it.
Create some class that can encapsulate a success and error state and all related info, return an instance of that.
I recommend option 1. You're already handling an exception, you can see its use for it error handling. No reason to stop it in its tracks there, handle any local cleanup then keep it going up to the caller.
Some hastily constructed examples now that I'm back at a keyboard, intended only to illustrate concepts, not to be exhaustive or necessarily used verbatim:
Cleanup then rethrow:
public boolean test () throws javax.script.ScriptException {
try {
transaction.begin();
...
transaction.commit();
return true;
} catch (javax.script.ScriptException ex) {
transaction.rollback();
throw ex;
}
}
Clean up then rethrow a different exception type if needed:
public boolean test () throws MyGreatException {
try {
transaction.begin();
...
transaction.commit();
return true;
} catch (javax.script.ScriptException ex) {
transaction.rollback();
throw new MyGreatException(ex);
}
}
Return an object that provides status information (this is just a quick example of the general idea):
public class TransactionResult {
private final boolean failed;
private final String reason;
/** Construct a result that represents a successful transaction. */
public TransactionResult () {
failed = false;
reason = null;
}
/** Construct a result that represents a failed transaction with a reason. */
public TransactionResult (String failedReason) {
failed = true;
reason = failedReason;
}
public boolean isFailed () {
return failed;
}
public String getReason () {
return reason;
}
}
And then:
public TransactionResult test () {
TransactionResult result;
try {
transaction.begin();
...
transaction.commit();
result = new TransactionResult();
} catch (javax.script.ScriptException ex) {
transaction.rollback();
result = new TransactionResult(ex.getMessage());
}
return result;
}
Etc.

Don't return anything. Just re-throw the original exception after you roll-back.
public void test()
{
try
{
transaction.begin();
code which may trigger exception
transaction.commit();
}
catch (javax.script.ScriptException ex)
{
transaction.rollback();
throw ex; // re-throw the original exception
}
}

If you insist, you can return Object. In that case, true will be autoboxed to Boolean.TRUE. It’s certainly not recommended, and it will give the caller some extra trouble figuring out whether the returned object is a String or a Boolean. To make matters worse, the caller has no guarantee that return types are limited to the mentioned two, but should also take into account that it could be yet another class.
Better options depend on the situation, so I probably cannot tell you what’s best. A couple of ideas spring to mind, but please don’t use uncritically: (1) Return String, and return null instead of true on success. (2) Design your own return class; for instance, it may hold both a boolean and a message string.

UGLY Workaround but if you really want to do this you can always define a Helper class which wraps status and Error Message, but I would prefer #JsonC's approach.
// Helper class
class Pair<First,Second>{
private First first;
private Second second;
Pair(First first,Second second){
this.first = first;
this.second = second;
}
public First getFirst(){ return this.first; }
public First getSecond(){ return this.second; }
}
// Function returning two types
public Pair<boolean,String> returnSomething(){
try {
return new Pair<boolean,String>(true,null);
}catch(Exception e){
return new Pair<boolean,String>(false,e.getMessage());
}
}
// Calling this method would look like this
Pair<String,boolean> result = returnSomething();
// Retrieve status
boolean status = result.getFirst();
// Retrieve error message (This is null if an exception was caught!)
String errorMessage = result.getSecond();

Exceptions can't go outside, it has to be handled here.
I must say this restriction can only make the interface more difficult to use. Assume you want to return something for the caller to check whether an exception happened in this method, while the caller can ignore the returned value no matter what. So I guess you want to give the caller some flexibility: that he/she doesn't need to bother with the final result if possible. But with the exception approach the caller can still do that, with empty (not recommended) catch clauses.
Exception is the best approach here. Unless "outside" is an environment where exceptions are not supported. Then you have no choice but to come up with something like Try in Scala.

In your case, exceptions should probably be used, not hidden. It's not a result but an error. Learn how to do exception handling in transactions!
Functional programming fanboys will advocate a Monad-like structure, as you can find in the Optional<T> API of Java 8.
I.e. you could return Optional<String> and leave it unset on success (if you do not have a return false and a return true).
For clarity it would be better to build something like this instead with custom classes:
interface Result {}
class BooleanResult implements Result {
boolean result;
public boolean getResult() { return result; }
}
class ErrorResult implements Result {
Exception cause;
public Exception getCause() { return cause; }
}
You could emulate Optional with null values (if you have only one boolean result). On success, return null. Non-null values indicate errors.
String perform() {
try{
...
return null; // No error
} except(Exception e) { // bad code style
return e.getMessage(); // Pray this is never null
}
}
String err = perform();
if (err != null) { throw up; }
Similar APIs are fairly common in old C libraries. Any return value except 0 is an error code. On success, the results are written to a pointer provided at the method call.
You could use Object.
public Object perform() {...}
Object o = perform();
if (o instanceof Boolean) { ...
This is 1980s programming style. This is what PHP does, so it actually is possible in Java! It's just bad because it is no lpnger type safe. This is the worst choice.
I suugest your try 1., 3., 2., 4., 5. in this preference. Or better, only consider the options 1 and 3 at all.
As for option 1. you really should learn how to use try-with-resources. Your transaction is a resource.
When done right, your code will look like this:
try(Transaction a = connection.newTransaction()) {
doSomethingThatMayFail(a);
a.commit();
} // No except here, let try handle this properly
Java will call a.close() even if an exception occurs. Then it will throw the exception upwards. Sour transaction class should have code like this to take care of the rollback:
public void close() {
if (!committed) rollback();
}
This is the most elegant and shortest and safe-to-use approach, as Java ensures close() is called. Throw the Exception, then properly handle it. The code snipped you showed above is an anti-pattern, and known to be very error prone.

If you are using Java 8 you could return an Optional<String>. Then if the code succeeds you return an empty Optional and if there is a failure you return an optional wrapping the failure message.

Why doesn't EJBException use Throwable.cause?

Quite for a long time I'm wondering why doesn't EJBException use standard Throwable.cause field to reach an exception it wraps?
It complicates getting the original root cause to something like that
private String getRootCauseErrorMessage(final Exception ex) {
Throwable currentException = ex;
Throwable nextException = null;
do {
if (nextException != null) {
currentException = nextException;
}
/* For some reason EJBException stores cause in a separate field rather the all generic Throwables */
if (currentException instanceof EJBException) {
nextException = ((EJBException) currentException).getCausedByException();
} else {
nextException = currentException.getCause();
}
} while (nextException != null);
return currentException.getMessage();
}
ps: I'm on Java6 and EJB3

Throwable.getCause was not added until Java 1.4. Some implementations of EJBException do retrofit the getCausedByException method to use the getCause method (similar to how the RemoteException.getCause method was retrofitted), but it sounds like your application server does not do this.