java null return vs good testable code rethinking design patterns

rethinking on design-patterns with null /empty handling scenarios

a function like below

  function(customerid){
      customer=findcustomerbyId(customerid)-->findcustomer
      list<Transactions> accounts=getNewTransactions(customer)-->findtransactions
      foreach{if(transaction.isGasTransaction()){send(event)..if()sendevent()}}-->send events
    }

now the question is whenever we are expecting a return value from a function ,should it be a null value ? or if the db can not find a value should it throw exception.

throwing null value forces you to write code to handle null-values/emptylists. which will increase if-else blocks and your junit cases also increase (directly proportional). throwing exceptions will force you to a different programming style and again you need some test cases expecting the exceptions.

like spring-jdbc template queryForObject throws exception if there is no value in db.(expected-1 but got 0)

what is the right direction here. more exceptions ? or use Optionsl<>java-8 like other null alternatives or use nulls?

we can balance these styles in different scenarios :)

so for a rest-api project i am thinking throwing exceptions will be good ,if you have a global-excpetion-handler(like controller advice) reason,you can handle exceptions in your code and not worry of method-stack to handle null checks/empty checks as exceptions are caught at advice level and is propagated accordingly.

*** this is to think in a direction rather than discussing which is best*****