My application syncs data between 2 different services. Data flow looks something like this:

Target <-- My Service <-- Source

I have a method that starts this batch operation:

// we have multiple organisations for which we do this

for each organisation:
void process() {
    1. fetch data from source
    2. fetch data from target
    3. process and decide which row to create, delete, update in target
      3.1 Update multiple rows in target
      3.2 Create multiple rows in target
      3.3 Delete multiple rows in target

1,2,3 are separate methods. 3.1,3.2,3.3 are separate methods called from method 3.

My question is that should I have any return type for methods 3, 3.1 ,3.2 and 3.3, as well as for process method. I am not able to see what would be the point? I am thinking of simply keeping it void. If some exception happens then that would be logged in the methods themselves.

So is there any point in keeping a return type in all these methods? And if yes, what should be it? And should I log it as info logs?

  • 2
    We can't invent imaginary business requirements for you. If you don't have a vested interest in returning a value, then don't return a value. Your question is asking to join the cargo cult. – Flater May 4 at 8:04
  • 3
    You are answering your own question. If you don't see a need for a return value then of course you shouldn't have one. Only write code you need! – JacquesB May 4 at 8:22

Returning an object that represents the result of a complex process can be useful, but only if it gets used. Since this process performs bulk operations, you could return an object that exposes information about the sub operations that succeed or fail. Some failures throw exceptions, and should halt further processing. Other failures might not require you to stop execution. If the caller can do something with this information then return a result object. If the caller cannot, then a void return type is fine.

Not the answer you're looking for? Browse other questions tagged or ask your own question.