| RE: [corona-dev] Exceptions in Corona. |
|
Keep in mind the distinction of error sources:
System exceptions can be caught / handled
/ swallowed in some cases. Piotrek proposed the use of NullObjects. I think they
should be used after catching or detecting "system errors" - if there
is an error is the application, its configuration or a subsystem. For example, null
object is returned if no Corona log service reference if found. What do you think? A method that is allowed to return regular
null should do it, but javadoc should specify that null is acceptable. The
invoker is expected to check for null value. More reading on exceptions: http://bdn.borland.com/article/0,1410,29664,00.html For remote / distributed systems http://www-128.ibm.com/developerworks/library/j-ejbexcept.html http://www.niwotridge.com/PDFs/ExceptionHandling3.pdf For .NET http://msdn.microsoft.com/library/default.asp?url=""> http://www.codeproject.com/dotnet/BestPracticesExcMgmnt.asp Pawel From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Everitt, Glenn Every new exception must have additional information in it beyond what
the base exception contains. Low level functions with minimal context need to wrap (new exception
and add nest original exception) the exception adding new information or if no additional
information is available throw exception up to the class that has enough
information for the "user" to understand. http://www.javaworld.com/javaworld/javatips/jw-javatip91.html
By
Terren Suydam The importance of a clean exception
definition To reap the benefits of this
technique and the multitier architecture, it's important to define specific
exceptions for each tier or logical level of code. … A good rule of thumb is that each
remote method on a logically defined tier should declare that it throws just
one exception (in addition to RemoteException): a nesting exception that nests
any of the exceptions that could be thrown within that method's implementation.
To reiterate a thought expressed earlier, this methodology plays perfectly into
interface-driven architecture: the implementation-specific exceptions are
abstracted into a singly defined exception for some interface method. Client side exceptions usually end up in dialog boxes presented to
people. People have a low tolerance for messages that have no information
that they can act upon. When you write the exception think about what the
recommended action to fix the error being reported. Server side exceptions usually end up in log files and being returned
to client code. Each "user" has information requirements. Please keep
this in mind as you work on adding exception handling. Try to think in terms of lower program levels communicating error
information to higher program levels. Try to be consistent in the API
about which type of class throws which of exception. Please make use of nested exceptions. They allow a user to see
information useful to them and programmers to see root cause. Thanks for playing Glenn Everitt -----Original Message----- In general I agree. If a null return is valid, I think it is OK return null. But defenitely we shouldn't return null when there was some exception within a method. Marcin Jaworowski, Piotr napisał(a): > Hi, > > I’m not sure if it’s a good idea to change all the
return null; > statements to exceptions, I would rather use Null Object pattern > instead (where it’s possible of course); > > Piotr, > >
------------------------------------------------------------------------ > > *From:* > [mailto: > *Sent:* Tuesday, October 03, 2006 12:24 PM > *To:* > *Subject:* RE: [corona-dev] Exceptions in > > Great idea. We also need to change returns of null values to > exceptional returns. > > Pawel > > The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. _______________________________________________ corona-dev mailing list corona-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/corona-dev The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. |