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 wondering how should I deal with the save method. Let's consider a situation when I want to register a new user. Firstly I need to check if there is one with that Id or login. If I can not find anyone I am able to create a new one and use save method from Spring Data.
What in the case when I found someone with such login? Should I throw an exception? I don't like them, for me, it's sometimes like running away from a problem. Returning a null instead of an object is not a good choice either, isn't it? That is my problem which I want to solve in the most gentle way. What to return and how to deal with such a situation. Maybe the exception is necessary? Then just handle it in my controller and deal with it. I hope you will advise me. I am rather asking for tips and a few words from experienced guys rather than getting an ordinary solution from the majority of pages on the internet. Thanks :D
An exception literally means "I couldn't complete this operation normally because of a circumstance outside the ordinary workflow", and AccountAlreadyExists is a perfect example of when to throw an exception. You're not "running away", you're informing a higher layer of the application that it will have to handle the problem. As a thought experiment: What if you have more than one reason that something could fail? How do you distinguish between null (duplicate account) and null (banned domain name)?
Note in this case that you definitely should have something like a UserAccountService whose responsibility is enforcing rules like "no duplicate accounts", and this will be the object that actually calls userRepository.save(newUser).
If you're using Spring MVC views, then you'll want to catch the exception in your controller and send the user to an error page. If you're using a JSON API, then you'll probably want to let the exception escape to return an error to the client; consider annotating your exception class with #ResponseStatus(UNPROCESSABLE_ENTITY) or similar.
Related
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 4 years ago.
Improve this question
I want such a script or logic so that if somebody has a copy of my code, they can only access/run it if they have my unique key, otherwise they get an error. Is there any way to do like this?
Thanks
If somebody has a copy of your PHP code they can run it. As PHP is not compiled, the possessor can read and edit the code as well; so even if you put in something that checks against a secret key, they could simply remove it. If you encrypt the code into an unreadable state, it’s also in an un-runnable state.
So, in brief, there really isn’t a way to give working PHP to another person in a way that they can’t simply run it. If you’re looking to sell a product of some sort, your best bet is probably to run it as a service so the end user never actually sees the code.
The closest you might hope for would be to make it difficult to read, i.e. with meaningless variable and function names and zero white space; but that won’t stop somebody who really wants it, (and who knows how to work some basic refactoring utilities), and only adds significant complication to your own work
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 4 years ago.
Improve this question
I'm currently developing a restful service using spring MVC.
I have read that logging is a cross cut concerning so I was wondering if it is bad practice to have log statements like log.info("A variable value") inside service facade methods.
Should we remove those log statements and put them inside an interceptor kind of object whose single responsibility is logging?
Is a method full of log.debug messages whose responsibility is to help tracing the method execution bad practice? If it is, how can we move this responsibility to a interceptor if the interceptor only have access to the method parameters
If I need a more informative tracing execution how can I achieve that?
If you do not understand what a method is doing there is a major problem, you have lost control of the software.
There are times when it is needed but should be removed as soon as possible. Among other things log statements make understanding the code more difficult by adding non-logic "noise".
Methods should be small enough that they are easily completely understood with only a small effort, with only a few exceptions. See "Uncle" Bob Martin.
I was brought in on one project because the performance way unusable slow. I solved that problem in a day, it was the logging, I removed it and the performance increased by a factor of > 25x.
It's not necessarily bad practice, but you should try and avoid the mistake twitter made where it's logging messages had user passwords in plain text before encryption
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 6 years ago.
Improve this question
This question is more about design than a technical problem.
I'm developing a backend application using java and Spring Rest Services.
It is a small application so in the beginning I just created a controller for all the end points (5 or 6 end points). I have for example an endpoint to request a token i.e /token, and another to make a request, based on the token received previously i.e /readresource.
So now I'm wondering if I should split the controller into two or more controllers, each one with the end points that are related to each other.
Of course in terms of legibility of the code this is useful, but also, from a technical point of view, if the default scope of a spring bean is SINGLETON, if I have only one controller, that would make only a single instance for the whole application, so let's imagine we have two requests that arrive to the server at the same time, even if each request is running a completely separate thread, and they are requesting different end points, in the end they are accessing the same instance so, one request should wait for the other to finish, we cannot execute on the same instance two different threads at the same time, am I right?
So... in terms of performance or good practices, is it better to avoid big controllers with many end points to have instead many small controllers?
What do you think about it?
Thank you!
we cannot execute on the same instance two different threads at the same time, am I right?
Wrong. This is only the case if the method that is being called has the synchronized access modifier. Otherwise, concurrent calls can occur on the same instance in different threads.
Having multiple controllers has no obvious impact on the performance of the application. It means an extra bean is loaded into memory, which equates to a few extra KB of RAM taken up.
This cost is far outweighed by having code that can be read and understood easily. Remember, you shouldn't write code for yourself. You should write it for the next guy, or as a man much smarter than myself once said..
Write your code as if the next person to read it is an angry psychopath, and he knows where you live.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I cannot seem to get this and yet i know it's something simple. getIntHeader doesn't work right, as it only returns -1. It's driving me mad, so i know fresh eyes will help my over the mental block.
Here is the line:
this.price = request.getIntHeader("price");
all suggestions are welcome
thanks in advance
Well per Java EE documentation -1 means that the header with the name you specified does not exist in the request.
So...
Check the name.
Look at the request in debugger or from browser or wireshark and see what headers it has.
Decide what to do with missing header, or whether you are just looking for the wrong one.
The name "price" doesn't look very conventional as the name of an http header.
And so you may be looking for something in a header that is actually delivered in another way, e.g. query parameter, form field, etc.
If your client is not sending a header, you can't receive and process it.
Java EE Doc I read was silent about what happens when the header exists but the value is not an integer, as a price often would not be. I would expect it might throw NumberFormatException in that case. But didn't try it, and it's conceivable it might eat the exception and return -1. I would bet it throws NumberFormatException, in that case.
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 just wonder about best way to write custom exception name, like if I have user and i want make exception for add and delete and update, what is better using names like :
UserAddException
UserUpdateException
UserRemoveException or UserDeleteException ?
or like:
UserAdditionException
UserUpdateException
UserDeletionException
Exception name must describe what it handle, but not sure use "verb" describe the action where exception happened or "noun" as what exception itself do.
What I want to understand here the best way that make developers understand my exception usage and what to use later, and if there is pattern or standard used for Java development in this case.
I would go with the second type of exception names. The reason why I would say that is because the exception: InstantiationException uses the noun InstantiationException. However, he most important thing is that you are consistent with the naming of exceptions and that the exception names give the development team a clear idea of what those exceptions indicate and their meaning. That is really the critical thing here.
What I would do will be, use UserManagementException instead of too many names, and specify the exact cause of it in some message or error code defined additionally in the class.