Java exception: throw back or send as return (function output)?

Question

Here's the usage: I am writing classes and functions which are designed to perform a specific function/task (for eg createBuilding, destroyBuilding etc). The design I am following is that the function does not process/handle any error scenario. Its the responsibility of the caller to take an appropriate action, in case there is an error/exception. I can do this in two ways:

public void caller {
  try {
      A.createBuilding();
  catch (Exception e) {
      process exception
  }
}

First approach:

public class A {
   public String createBuilding throws Exception {
     try {
        blah blah blah
     catch (Exception e) {
        throw new Exception(e);
     }
}

Second approach:

public class A {
   public String createBuilding {
     StringBuffer sb = new StringBuffer();
     try {
        blah blah blah
     catch (Exception e) {
        sb.add(e.toString());
     }
     return sb.toString();
}

The user in the second case does the following:
public void caller throws Exception {
      String st = A.createBuilding();
      if (st.contains("Exception"))
        do something;
}

Assume that the called function always returns a string.

Any comments on which approach is better? Any pitfalls/issues I am overlooking?

Appreciate all the help!!!

Solution 1

Use the first one ofcourse, i.e use Exceptions.

The second one breaks years of research on error handling, dont do it.

Reason: If you use Exceptions you will be able to leverage the entire error-handling framework in java build around exceptions like Thread.uncaughtExceptionHandler and stack-traces etc. Also using excpetion is the preferred way of error handling and will be recommended over returning custom strings to identify errors

Solution 2

Returning a string removes information (like the stacktrace.) If your method does not handle the exception, it should not catch it and let the caller handle it:

   public void createBuilding() throws Exception {

        blahBlahBlah();
   }

Comments

[Marius Burz]

Partially valid only for Exception, not so for RuntimeException. Sadly Exception is definitely underused by too many a developer.

[rsp]

@Marius, Exception in the answer is used as example to be replaced with the exception type actually used. The point is that you should not catch and rethrow exception, if you do not act on them.

[Rahul]

This is exactly the problem I face. If I get a run time exception, the only way to send it back to the caller is to catch the exception and throw it back (new throw...). If there is a long stack of calls, each caller needs to do that and thats kind of painful. So if I have something like Caller A->Caller B->Caller C and C throws a runtime exception, whats the best way to get to caller A without everyone catching and re throw it???

[rsp]

@Rahul, the best way is to let caller A catch the runtime exception and not to catch and rethrow it. The fact that you do not declare runtime exceptions as being thrown from your methods does not mean that they stay inside your method, they unwind the call stack untill they are caught. If you decide that your API should throw it's own type of exception you should catch the runtime exception at the lowest possible point, wrap it in your own exception type and throw it. Do not catch and rethrow it on its way up. Do not forget to use finally {} blocks for cleanup code.