Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Many methods in my code I am currently working on follows a certain pattern:
public void aMethod(...) throws CustomException {
Log("aMethod Started")
try {
//Many method calls that could throw a CustomException
} finally {
Log("aMethod Ended")
}
}
Changing anything about the CustomException is not an option.
Is there any better alternative that doesn't work with try finally?
I would say
finally {
Log("aMethod Ended")
}
is not good way to log ending of method.
If an exception occurred the method has not actually ended but interrupted and returned without completing.
So, the "Log("aMethod Ended")" shall be outside of finally. If end logger is missing in that log, you will anyway get from the exception stack trace.
If you want to just log weather the method was called and then left, then Spring AOP is what could be implemented for the whole product configuration, so you wont need to duplicate the logger everywhere.
On the other hand, if you personally feel this logger wont be of much use and just redundant information; then just turn off that rule in solar lint configuration.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am implementing a DELETE rest endpoint in spring boot, I am not sure which approach is better between below 2 approaches:
First checking if the record with given Id exists in the database and then delete it safely.
Directly calling delete on spring data repository and catching EmptyResultDataAccessException thrown by spring data to return 404 response.
I like the first one as the code is more readable and does not involve controlling flow using exceptions. However, it involves an additional call to db and potential race condition.
Why would you prefer the first or the second approach?
If you annotate the service method with #Transactional there will be no race condition and it's fine to check for existence first (with a small performance overhead).
On the other hand I always like the simplicity of attempting the deletion and catching the exception, the assumption being that deleting a non-existent resource is exceptional.
Note also that in REST a DELETE on a non-existing resource should normally return a succesful HTTP status code 200 (OK) or 204 (NO_CONTENT).
#Transactional
public Response deleteAfterChecking(Thing thing) {
if (!repository.exists(thing)) {
repository.delete(thing);
}
return Response.NO_CONTENT;
}
public Response deleteHandlingException(Thing thing) {
try {
repository.delete(thing);
}
catch (NotFoundException e) {
// do nothing
}
return Response.NO_CONTENT;
}
The first option is better conventions-wise and will be more readable, but not performance-wise on big amounts of data as you will need two calls. Indeed, you should not need to catch an EmptyResultDataAccessException at any point.
You should nonetheless think about your code conception. How can the ID of a potentially non-persisted object be passed ? Is it necessary ? Without your code, I can't judge, but I believe you should consider this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When I was reading Core.Java.Volume.I, I can't understand the meaning of this:
"Be careful to ensure that the code in a critical section is not
bypassed by throwing an exception. If an exception is thrown before
the end of the section,the finally clause will relinquish the lock,
but the object may be in a damaged state."
How can I ensure that? Isn't the code in a critical section must to be bypassed when throwing an exception?
Consider this pseudocode:
Patient patient = service.getPatient(name);
hospitalEquipment.lock();
try {
patient.pauseLifeSupport();
// some code causing an exception
patient.resumeLifeSupport();
} finally {
hospitalEquipment.unlock();
}
In this pseudocode the exception causes a "critical section" to be bypassed, namely resuming life-support. You could potentially fix this by moving the call to resumeLifeSupport() inside the finally block or have some emergency behaviour.
Add your own code in finally section to ensure that the object is in a safe state. How exactly to do that? Depends on the object and the state.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For better designing application:
Where to handle exception whether in DAO layer or Delegate layer?
Which one is better approach out of 2 given in 1?
As usual with "design" questions: It depends.
In general, I would say handle as many exceptions as possible locally, in this case in the DAO, but you may want to re-throw some exceptions or raise new ones directly.
E.g. if your DAO causes an SQLException, you do not want to let your upper layers even know that SQL is used, so catching this exception early on would be advisable (so you don't have to import SQLException in your Delegate Layer's package). However, re-throwing the SQLException inside a MyCustomDAOException will allow to retain the error information.
tldr; In the DAO, and throw new Exceptions containing the original one if needed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
THROW:-We have to handle the exception(we in the sense user here).
Throws:We are asking the compiler to handle the exception raised.
Please correct if what I stated above is wrong . If wrong please tell me the correct statement.
Thanks in Adv!
I'd say that both are not exact.
throw statement causes throwing of exception. No-one has to catch it however. For example runtime exception can be thrown without any requirement to catch them in application code.
throws is a keyword that allows to declare that method may throw exception of specific type.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I was reading up this code review questions here and tutorial by BalusC. In that I have found that exception classes are extended.
What is the need of it? I read something along the lines of client layer should not know SQLExecption but I am not sure I understand it.
Could you reason why to make specialized exceptions? What if my DAO method does not have throws and the client code is in a try-catch.?
Because DAO could be today throw SQLException tomorrow if you want to change DAO layer to write to File, it might result in FileNotFoundException, So hiding underlying stuff you show to your client what matters to them (custom business sensible Exception)