cancel
Showing results for 
Search instead for 
Did you mean: 

Exception declaration for methods in a Controller

Former Member
0 Kudos

Hi all enthusiasts of WD,

me again :-). I just noticed that one cannot declare exceptions thrown by a public method in a controller. Is it on purpose to shut down exception handling?

Maybe it makes sense to forbid this for the component interface controller, since the interface controller is accessible outside the component, it's not a good idea to ask other components to handle the exceptions specific to one component (after all, a component should be a self-contained unit); but for other controllers like component controller, it's convenient and safe to allow exception declaration --- it can only be accessed inside the component anyway.

Will this be supported in the future? Thanks.

Best regards,

Ge

Accepted Solutions (0)

Answers (2)

Answers (2)

BeGanz
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hallo Ge,

you are right; the Web Dynpro metamodel/generation framework does not specify defining exceptions for public Web Dynpro controller methods in SAP NetWeaver 04 and 04s.

This is first possible within the new SAP NetWeaver 7.1 Composition Environment so that you can enrich your Web Dynpro custom controller code with checked exceptions.

Regards, Bertram

Former Member
0 Kudos

Hi Bertram,

Thanks very much for the reply. Seems quite a few great features will be available in NW7.1.

Points rewarded.

Regards, Ge

Former Member
0 Kudos

Ge,

Interesting question.

I would like to here the answer from WD team too.

Btw, if you need to throw exception you may declare your own excpetion hierarchy as sublasses of java.lang.RuntimeException. It's not mandatory to enumerate subclasses of RuntimeException via "throws" clause but you still can catch and handle them. Thoug, the methods with unchecked exceptions are no self-documented about possible failures as ones with checked exceptions.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

Former Member
0 Kudos

Hi Valery,

your suggestion could be a good solution for now, one just have to make sure to handle all RuntimeExceptions, which could be a little bit hard and unneat. Still I have some worry about this approach, with an uncomfortable feeling about potential misuse of RuntimeException, since it normally implies a programming error or configuration error, while checked exceptions tell about the "normal" failures of a method.

The more serious consequence is if one forgets to catch a custom RuntimeException, it will cause a dump, which is not acceptable for it's indeed just a "normal" failure, the user should get a message instead of a dumping page; to make things even worse, it cannot be checked at build time, and might as well escape from the testers and comes up at the customer side (after all our software is not supposed to fail that often ). I would rather accept the current status and wait for an answer from WD team to save my life,

But thousand thanks for the kind reply, points rewarded. : )

Best regards,

Ge

Former Member
0 Kudos

Ge,

You misinterpreted my answer a bit.

1. Create own subclass of RuntimeException so you may distinguish your exceptions and standard ones like NullPointerException, ArrayIndexOutOfBoundsException:


public class GeRuntimeException extends RuntimeException {
  public GeRuntimeException(final String message) { super(message); }
  public GeRuntimeException(final Throwable cause) { super(cause); }
  public GeRuntimeException(final String message, final Throwable cause) { super(message, cause); }
}

2. Next create concrete sublcasses of your superclass:


public class GeSecurityException extends GeRuntimeException {
  ...
}
...
public class GeDatabaseException extends GeRuntimeException {
  public GeDatabaseException(final java.sql.Exception cause) { super(cause); }
}

3. Typical code pattern that throws your exception:


final PreparedStatement pstmt = ...;
try {
  pstmt.setInt(1, 0);
  pstmt.setString(2, "String param");
  pstmt.executeUpdate();
} catch (final SQLException ex) {
  throw new GeDatabaseException(ex);
}

4. Typical code pattern that handle exception:


try {
  wdThis.wdGetOtherController().makeDatabaseCall();
} catch (final GeDatabaseException ex) {
  wdComponentAPI.getMessageManager().reportException( 
    new WDNonFatalException( ex.getCause() ), false
  );
  return;
} catch (final GeRuntimeException ex) {
  wdComponentAPI.getMessageManager().reportError("Unexpected failure");
  return;
}
/* Some other code if no exception */
...

Notice that code above does not catch generic RuntimeException, only your sublcasses.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

Former Member
0 Kudos

Hi Valery,

I got your point, I just pointed out since any RuntimeException (or its subclasses) will not force the calling method to handle them, one (like stupid me ) might forget to handle one and this would be likely ignored until it comes up at customer side some day (just imagine if one uses RuntimeException to indicate IO exceptions)...

And I totally agree with your point about NOT throwing and catching generic Exceptions like RuntimeException or Exception itself, that would be a nightmare, especially when someone just catches and swollows them, which I unfortunately have seen quite a few time. God bless them

Thanks again for the reply. You seems to be a real enthusiast here.

Kind regards,

Ge

Former Member
0 Kudos

Oops! Sorry for misunderstanding you.

I just say the same above (also in bad English with typo): "Though, the methods with unchecked exceptions are <b>less self-documented about possible failures</b> as ones with checked exceptions."

VS