----- Original Message ----- From: "Wouter Zoons" <[EMAIL PROTECTED]>
To: "Stefan Siegl" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 27, 2004 5:11 AM
Subject: Re: [Andromda-user] How to model exceptions correctly
One additional question, though. As far as I understand this, it is only possible to model exceptions that will be thrown by all business methods of the model class. So if I want a business method test() to throw only exception E1 while method test2() should throw only E2, it is not possible?
this is not possible, we've had discussions about this almost 2 years ago now, the bottom line is that it is a good practice (and this is my personal experience too) to have the services only throw a single exception (in which you wrap the actual exception)
-- Actually it is possible, you can just draw a dependency from the operation to the exception(s) that you want thrown for that particular operation (or you can do it from the <<Service>> as well, either way.
there are many reasons I like this concept, but the most important one is the straightforward integration with the presentation layer .. also, specific exceptions are changed/added often because method implementations can change a lot and if you model them explicitely you are changing the signatures each time .. if you have a wrapper exception you don't need to worry about this
anyway, the most important reason for me is that writing the Struts code (controller implementation) does not change when updating the services
if you really would like to have this support I guess it should be possible to model it and have it properly rendered for a single operation .. but it's not the area on which I focus in AndroMDA ..
Wouldn't it be helpful to integrate this behaviour as well? The only solutions that come direclty to my mind have flaws, but I will briefly describe them, perhaps they are ok. 1) add a tagged value to the method that describes all exceptions that are thrown. Problem here is that the name of the Exceptions must be entered by hand (including the package name) and no support by the modelling tool is provided if a Exception class is renamed or refactored to another package. 2) Define the exceptions as dependencies put add a tagged value to the dependency defining for which method of the service this exception should be thrown (perhaps as a regular expression).
What do you think about that?
in MagicDraw you can have dependencies from operations to classes :-) just as UML allows
I will leave the implementation to Sascha (he's maintaining the EJB-cartridge, used for the session beans), anyway .. it would be for after the next release though (3.1), we are not adding features to 3.0 anymore
thanks for your feedback -- Wouter
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=ick _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
