#Service and ServiceImpl

26 messages · Page 1 of 1 (latest)

ripe sonnet
#

So I've started fixing up the services based on this discussion (https://discord.com/channels/648956210850299986/1142913564856832144)

So I changed the abstract classes to an interface and moved the implementation to the real implementation classes. Why am I making this post? Well the service methods are called from the controllers as expected. The service methods throw checked exceptions which I use in the controller to answer different with different responses based on the exception. The problem is that my interface methods look like this:

void saveBusinessUnit(BusinessUnitDTO businessUnitDTO) throws FailedToSaveException;

It looks like something that shouldn't be there but I'm not really sure if what I've made is stupid.

From the top of my head I have 3 solutions.

  1. Leave it as it is - throws in both the impl and interface requiring anyone who makes a new service impl in the future to have to throw them (probably won't require changes in the controller. But limited in the future in case there is a need to add different exception)
  2. Remove the throws from both the impl and interface and return a more generic response to the client (Will be hell to debug on why the call failed from the client side)
  3. Make it a unchecked exception and throw the exception without limiting people to who might want to make a new service (Might lead to tons of confusion and hidden exceptions which aren't handled)

(Nobody would touch the code except me. So just looking to learn how I should go about this. Thanks!)

zinc ruinBOT
#

⌛ This post has been reserved for your question.

Hey @ripe sonnet! Please use /close or the Close Post button above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically closed after 300 minutes of inactivity.

TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.

vital marsh
#

you could wrap the exception into something that matches your interface

#

and implementations don't have to throw the exception

ripe sonnet
#

Wdym by wrap the exception into something that matches your interface?

vital marsh
#

you create your own exception class

#

that logically works with the interface

#

BusinessUnitException or whatever

#

some exception that works for all possible implementation

#

and in your implementation, you can catch the FailedToSaveException and then do throw new BusinessUnitException(e);

#

essentially, you should ask yourself what the interface should look like

#

and then adapt the implementation to the interface

ripe sonnet
#

These are already custom exceptions. That's my 2nd point from the above post. I can probably go without them at all. Thing is it will be hell communicating with the client like this. Do you think this is the best solution?

vital marsh
#

well the generic exception can still contain a "caused by" with the original exception

#

and if an implementation doesn't throw an exception, it doesn't need to

ripe sonnet
#

yeah fair enough. Lemme think about it a little

#

ffs, intellij was playing games on me

#

it was telling me implementations have to throw the exception cuz that's how it was defined in the interface

#

(or I probably read something wrong)

#

and now it lets me just not have the exception thrown in the implementation

#

ohh nvm it was backwards. I tried to remove the exceptions from the interface and I was told I can't add exceptions in the implementation

zinc ruinBOT
vital marsh
#

yep

#

all checked exceptions thrown in an implementation also need to be thrown in the interface