Thanks for explaining the reasons behind the decision to me. Actually
the longer I think about the one general exception per component
concept, the more sense it makes to me. The only drawback is if a
business method does not throw an exception the client is still forced
to do exception handling.
Stefan
Wouter Zoons wrote:
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)
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
--
Dipl.-Ing. Stefan Siegl
Email: s.siegl <at> novatec-gmbh <dot> de
NovaTec - Ingenieure f�r neue Informationstechnologien GmbH
Dieselstr. 18/1
70771 L.-E. Echterdingen
Phone: 0711/22040-814
-------------------------------------------------------
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
