| RE: [corona-dev] Exceptions in Corona. |
|
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 |