title: Is it a good practice to write methods that return void?
body: <p>I am working on a complex enterprise application coded in java that is driven by complex object compositions. For example : In a particular scenario, to perform an action this is the flow:</p>
  
  <pre><code>login() -&gt; 
  Followed by defined sequence of 10 to 20 method calls in different classes -&gt; 
  Followed by a logout()
  </code></pre>
  
  <p>Within the framework, almost all the actions including the login, logout, and many of the 10 to 20 method calls have no return types. Any erroneous behavior is handled by the framework. Say, in login </p>
  
  <pre><code>public void login(){
  try{
   //login actions
   //chained sequence of calls
  
  }catch(){
   // framework handling exceptions and other rollback options
  }
  }
  </code></pre>
  
  <p>The intermediate 10 to 20 actions are method calls on different objects at different levels of hierarchy of the framework.  </p>
  
  <p>A random class would look like this :</p>
  
  <pre><code>class someobject{
  
  def variable
  
  void action1(){ do something on variable }
  void action2(){ do something on variable }
  ...
  }
  </code></pre>
  
  <p>The variable changes state often and these actions have a sequence defined only by the framework which I find very annoying. </p>
  
  <p>I'd say, Probably if there were appropriate return types at all or at least some of these methods, as in say boolean in the case of <code>login()</code>, life would be a lot easier. Because of this tight adherence to a series of void returning functions, I find it difficult to debug through to understand the flow and also unit testing became a nightmare to me.</p>
  
  <p>So now, I am under the impression that it is always better to write functions that return something, <em>especially when there is a chain of actions involved</em>. So, Is this a safe presumption? I'd want to take your opinions on this. Do correct me if I am wrong. </p>