Hallo Pete, > Good software always shows symmetry. However, the an entity bean's remove method can > only throw RemoveException (or derived exceptions of course). There is no way i can > extend the remove method to throw a custom application exception (like my own > "ValidationException").
The create and remove methods are not symmetrical. The create method can have arguments that you might want to validate in the bean class. The remove method does not have any arguments that you need to validate. Why do you want it to be able to throw a validation exception? If you want to control when the application programmer is allowed to remove the bean, you should use (a subclass of) the RemoveException, which is there for it (see API). Regards, Dies > > I think of a few solutions, but i dislike them all: > > 1) let the remove throw an application exception derived from RemoveException => > application programmer might forget to catch and handle the validation exception, > because it is not explicit in the interface (of course he _has_ to catch the > RemoveException, but he might not notice that there is a validation exception > 'inside') > > 2) split the remove and put the validation in a "pre-remove" method, that must be > called by the application programmer before calling the real remove => no guarantee > that the pre-remove is always called before the actual remove > > 3) session facade: calls remove and catches and handles the validation exception => > (a) i don't want session facades (b) no guarantee that the ejb remove is not called > directly > > I would think more people might have encountered this issue ;-) > > Any ideas, suggestions? > > Cheers, > Pete =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
