Kirk James

Thanks for your help guys

Thank you for your opinion, so, about the scenario I showed previously, do you think that a checked exception could be a better solution?

Supposing that UserNotFoundException is an UncheckedException, I will not force the external layer (Controller) to catch the exception and build a specific body for the Client, in that case so it will be handled as a generic Exception (500) instead of a not found (404)

Snippet edit:

} catch ([b]UserNotFoundException[/b] e) {            log.error("log the exception");            response.setInformationOutcome(buildTheOutcome());            return new ResponseEntity<>(response, HttpStatus.NOT_FOUND);        }

Claude Moore wrote:Have a look at Java Documentation. In a nuthshell, you should use unchecked exception when dealing with unrecoverable errors (a stack overflow, a connection to a DBMS dropped).
My personal taste: use checked exception as much as possibile in your business layer.

Actually I want to recover from every exception by catching it and building a proper body for the Client side of the application.

I mean, when I think about a recoverable error I suppose that somewhere in my code the exception is catched and nothing will be rethrowed back from it.

} catch (Exception e) {            log.error("log the exception");            response.setInformationOutcome(buildTheOutcome());            return new ResponseEntity<>(response, HttpStatus.INTERNAL_SERVER_ERROR);        }

Hi guys,

I have to ask you a question about the decision to throw checked or unchecked exceptions in a multilayer application.

Let's say that I've the following structure:

- Controller class that will call the Service layer and handle exceptions, returning a body response to the Client.
- Service class, will implement the business logic.

The Service class impements a method to retrieve the User data from a database, a simple findById().
In case of entity not found I would throw a custom exception, let's say UserNotFoundException, that the Controller class will handle, building a proper response to the Client.
The UserService class is called only but the UserController, no other Controller or Service makes use of it.

The question is, should the UserNotFoundException implemented as an unchecked (runtime) or checked exception (force the Controllare layer to handle it)?

Generally, which kind of rule should I follow to decide how to implement an exception handling process?

Thanks for your help.

Paul Clapham wrote:Good to hear that!

As for "what happens under the hood", that isn't what you need to know. You need to know how variables work in Java. Here's a link to a pretty decent tutorial which tells you about that: Variable Scope in Java.

And then you say that some other code tries to use some other value, and it's null. Right?

Well no, it's not what I'm saying or what I tryied to say.

Thanks for your help but I think you misunderstood the point. The behaviour I was facing was not inside the aspect but inside the method that is matching the aspect:

playerRepository.findById(id) was returning null as result, even if the entity exists, so I was facing a null pointer exception: playerRepository.findById(id).orElse(null);.

I'm not sure that it's related to the variables scope, but if you say that for some reason the variable result is needed by the getById method, so probably it could be related to that variable (not specifically about the scope you're telling me), then if it is I want to know the reason why.

Well, it seems I found the problem, I need to return the result in my aspect:

   @Around("findRepositoryMethodExecution()")    public Object  aroundFindRepository(ProceedingJoinPoint joinPoint) throws Throwable {        String methodName = joinPoint.getSignature().toShortString();        String args = Arrays.asList(joinPoint.getArgs()).toString();        log.info(ACCESS_LOG + " data FIND operation: {} | args: {}", methodName, args);        Object result = null;        try {            result = joinPoint.proceed();            log.info(END_LOG + " method: {} | result: {}", methodName, result);        } catch (Exception e){            log.error(ERROR_LOG + " AOP aroundFindRepository: ", e);        }        return result;    }

Can someone please explain me what happens under the hood?

Hi guys,

I'm facing a weird problem using Spring-AOP, Spring-Data and H2 in memory database.

This is my aspect:

@Around("execution(* mypackage.myrepository.findById(..))")    public void aroundFindRepository(ProceedingJoinPoint joinPoint) throws Throwable {        String methodName = joinPoint.getSignature().toShortString();        String args = Arrays.asList(joinPoint.getArgs()).toString();        log.info(ACCESS_LOG + " data FIND operation: {} | args: {}", methodName, args);        try {            Object result = joinPoint.proceed();            log.info(END_LOG + " method: {} | result: {}", methodName, result);        } catch (Exception e){            log.error(ERROR_LOG + " AOP aroundFindRepository: ", e);        }    }

this is my joinpoint:

   @Override    public Player getById(Long id) throws PlayerNotFoundException {        PlayerEntity playerEntity = [b]playerRepository.findById(id).orElse(null);[/b]        if (Objects.isNull(playerEntity))            throw new PlayerNotFoundException();        return mapper.map(playerEntity, Player.class);    }

Well, the problem is that, the joinpoint is working, matching the findById method, the problem is that playerRepository.findById is returning null (even with an id of an entity that really exists) and I'm facing a null pointer exception.

This is what I see from the logs:

- [ACCESS] data FIND operation: CrudRepository.findById(..) | args: [1]

- [END] method: CrudRepository.findById(..) | result: Optional[MyEntity my properties bla bla bla]

- java.lang.NullPointerException: null


So it's really strange, because I see that the Aspect is working and is retrieving correctly the entity, but when it proceed to the real method then playerRepository.findById return null.

Can you help me to solve this problem?

Thanks!

Hi guys,

what I want to ask is why the following practice is a good one whenever you have to create a WS architecture (but maybe this could not be the only case but a generic good practice):

@RestController @RequestMapping("/service") public interface Api { }

@RestController public class Controller implements Api {    private Service service;    @Autowired    public Controller (Service service) {        this.service= service;    } }

Why we should expose an interface marked as our API (Api interface) instead of expose the class that implement that interface (Controller class)? Do we follow some specific practice or principles doing this?

Thanks.

Clear, many thanks.

Hi all,

the following code shows a REST endpoint made with SpringMVC module:

   @PutMapping("/user")    public Response doSomething(@RequestBody Body body) {        Response response = new Response();        response = service.doSomething(body);        return response;    }

The PutMapping annotation doesn't provide a consume or produce element that could be: @PutMapping(value = "/user", consumes = MediaType.APPLICATION_JSON_VALUE, produces =  MediaType.APPLICATION_JSON_VALUE)

Is that option (consume/produce) mandatory for some reasons? Why I should use it or not? If I try to make a call with a client (Postman) I can send a JSON format request even if I don't provide the consume/produce element for this endpoint.
Can you please give me more explainations?

Thanks.

Tim Holloway wrote:You confused me. I call "DML" SQL. Since basically, DDL is the part of "SQL" that isn't actually SQL and SQL is the part that was defined by Codd and Date.

Anyway, as I recall, auto-commit is on by default with MySQL and PostgreSQL and probably Oracle, SQL Server and DB2.

Realistically, saving stuff up to do a commit is something more common to programming than for just fiddling around with the database manually, so I'd expect auto-commit to be the default in general.

But I don't think that it's actually mandated anywhere. For that matter, I don't think that there's a standard that says a DBMS even has to have a command line interface application. Although it's going to be a lot less fun tweaking things without one.

About the DML, I use to define DML as Data Manipulation Language, so everything related to your database manipulation (INSERT, DELETE, UPDATE), then DDL as Data Definition Language, everything related to the definition of your data architecture (ALTER, DROP). When you say that:

DDL is the part of "SQL" that isn't actually SQL

sorry but,  I got confused.

Thank you for your reply.

Tim Holloway wrote:Actually, while it might vary depending on which DBMS you're using, I've always seen DDL auto-commit. And actually, having to explicitly commit DDL sounds a bit problematic to me.

What about DML? no auto-commit by default? Never worked on the DBMS settings, probably that behaviour can be managed.

Hi,

as far as I know DDL commands such as an alter/drop table are by default setted to autocommit on a RDBMS; on the other hand DML need an explicit commit operation.

Can someone confirm that assumption or explain me if some RDBMS have a different behaviuor?

Thanks

Paul Clapham wrote:Technical? I don't understand what you're asking.

I was just talking about the Spring IOC container that manages the bean instances and that cannot work with static elements.

Paul Clapham wrote:

Kirk James wrote:Injecting static fields looks like a wrong usage of an OOP pattern (dependency injection), also static fields belong to a Class, not to an Object;

Those are both good reasons not to inject static fields, so I think you have the answer well-covered.

On a techical side, what could be the reason of that behaviour?