How to throw exception from Listener's Event Methods

Question

Hi,
We are using Jdev 10.1.3 and I'm implementing a class that implements EntityListener and RowSetListener interfaces.
The problem that i'm facing is when I override the event methods of the interface (Which don,t throw any exception) , I'm not able to throw any exceptions in overridden methods also. Kidnly guide me on how to achieve this...
Sample Code :
public class GenericHistoryViewObjectImpl extends ViewObjectImpl implements RowSetListener
// this event is fired when a row is deleted from rowset and it registers data in history
public void rowDeleted(DeleteEvent event)
latestEvent = "DEL";
try
GenericHistoryManager.registerDataInHistory(this);
wasLastEventExecutedSuccessfully = 1;
catch (Exception e)
e.printStackTrace();
wasLastEventExecutedSuccessfully = 0;
genericHistViewException = e;
from The mothod public void rowDeleted(DeleteEvent event) of RowSetListener i want to throw an exception ...

Answer 1

JSalonen is totally correct. I would only add that this topic, generally, exposes the differences between checked and unchecked exceptions. Unchecked exceptions extend RuntimeException or Error. Checked exceptions extend Throwable or Exception. There are important differences.
Checked exceptions must specifically be caught or declared in a throws clause of a caller. Unchecked exceptions do not have this restriction. This means you can always 'wrap' (or throw without wrapping) an unchecked exception. Unchecked exceptions are very useful. You can use an existing unchecked exception, or create your own by extending RuntimeException or Error.
To illustrate the difference, let's say we are creating a new user account and storing it in the database. For a checked exception, I might define DuplicateUserRegistration in case a user registers with an existing user name (a non-fatal error case that can be anticipated in system design). However, if the database was down, I would not throw SQLException (which is checked) but rather something like ResourceUnavailableError. This would be unchecked. A calling class (normally) will not be able to realistically handle a situation where the database is down, so why force that caller to either declare throws SQLException or catch SQLException for this instance?
- Saish