Shipatrioc http://www.jdon.com Dec 3, 2004 8:04 PM Reply
This is the error prompt that the web end to the client in the system is displayed in accordance with such a Class.
Public class errorcode {/ ** Error code * / private string code; / ** Error name * / private string name; / * Error Description * / Private string description; // Other setter / getter method of the fields Above .. ....
All exceptions come from the Business delegator packaged for the Session Bean method.
I am calling the session bean method in this business delegator, and generates the captured exception to generate an ErrorCode object to return to the web terminal. My current practice is as follows:
public class MyBusinessDelegator {private ErrorCode errorCode; public ErrorCode getErrorCode () {return this.errorCode;} public String getWeight (String name) {try {return invoiceSetting.getWeight (name);} catch (BusinessException ge) {errorCode = new ErrorCode ( ); // ------- ErrorCode.setCode ("2000"); error.setname ("The person does not exist"); errorcode.setdescription ("The person does not exist"); return null;} catch RemoteException Re) {ErrorCode = New ErrorCode (); // ------ ErrorCode.setCode ("2000"); ErrorCode.setName ("System Error"); ErrorCode.SetDescription ("System Error); Return Null;}}}
When there is a lot of such a method, the code looks at the urgly. But every time you capture an exception, you have an errorcode, because if you don't get, the client is possible to get the ErrorCode information called last time. I want to ask. Can you improve this code through a mode or some design.
Re: Error code design! Published: DEC 4, 2004 9:11 AM
Reply Poster: ShipatrioC Post article: 12 / Registration time: 2003-08 Thinking of the solution, put errorcode inherit the Exception, then BusinessDelegator should be thus line, so that the web is still to capture a checked exception! Other people have Good solution?
Re: Error code design! Published: DEC 4, 2004 1:32 PM
Reply Poster: Nekesai Post article: 44 / Registration time: 2004-10 Our approach is this: All ErrorMessage is configured outside the XML file outside, avoiding too much Hardcode. In the context, personal suggestion is to map the ErrorCode class to a ERRORMESSAGE DTD or Schema, and the value of all Code, Name, Description in ErrorMessage.xml will be created from ERRORMESSAGE.XML in the future. It is best to create these three values. Out of the ERRORCODE instance pass, you can throw out. This advantage is to avoid hard coding and encoding amount, and the idea is relatively close to AOP. Re: Error code design! Published: DEC 4, 2004 2:21 PM
Reply Poster: Shipatrioc Post article: 12 / Registration time: 2003-08 Oh, the storage of error messages I think so, put the initialization error code in a stack block, the efficiency should be higher, the shortcomings are maintenance errors Information is still going to be maintained in the code. During another question, we generally define a lot of check exception in the sessseion bean, then capture in Business Delegator, then make error code to a public commonException, then throw to the front desk For example, in the STRUCTS Action, it is finally given to the user an error page. I think is it possible to throw this CommONException directly in the sessseion bean (information on the error code), which can omit a lot of Exception Class. Is this shortcoming? ?
Re: Error code design! Published: DEC 4, 2004 8:51 PM
Reply Poster: Nekesai Post article: 44 / Registration time: 2004-10 Stateless session If it is made as FACADE, the add-to-deepening change can be called each DAO, unified through the Stateless session that is made as a Facade. To perform the operation. STATELESS SESSION is just like a corresponding DAO class name. The ADao impletements DaoInterface {create () update (); delete (); findByPrymaryKey ();} BDao impletements DaoInterface {create () update (); delete (); findByPrymaryKey ();} SessionBeanFacade {Map daoInstanceMap = new HashMap () ;. create (String className) {if (daoInstanceMap.containKey (className)) return ((DaoInterface) daoInstanceMap.get (className)) create (); else {DaoInterface daoImp = ((DaoInterface) Class.forName (className) .newInstance ) .create (); DAOINSTANCEMAP.PUT (Class, Namedaoimp); Return Daoimp.create ();}} Update () {........} delete () {....... }..........it's the same. } I don't know if I can give it to you.
Re: Error code design! Published: DEC 4, 2004 9:05 PM
Reply Poster: Nekesai Post article: 44 / Registration time: 2004-10 Haha, sorry, reply to make a mistake. If we need to truly understand the main reason for Exception, we still throw an exception that represents different layers. Of course, no matter which layer you can throw the same COMMONEXCEPTION, final to the client. But this is not good to locate the wrong place and understand the real error. So our approach is to define the exception of each layer. That is, the persistent layer Exception, the business logic layer Exception, the agent layer Exception, the unified Exception of the final client Catch. But such a disadvantage is indeed exception subclass. I don't know if I can give you a useful information, and other travel friends can tell individual experience. Re: Error code design! Published: DEC 5, 2004 10:44 AM
Reply Poster: Kidwish Post article: 31 / Registration time: 2003-08 See Hibernate's abnormalities, you can inspire and help you! Since the code is more, it cannot be posted. Core explanation how to handle Checked Exception and Runtime Exception! Sub Question: Record the nesting exception, complete exception information
Re: Error code design! Published: DEC 6, 2004 10:02 AM
Reply Poster: ljshan Post article: 15 / Registration time: 2004-11 Anomaly is also an integral part of the interface. It is recommended to use the abnormal processing mechanism of the language itself, using a specific exception type (of course, the exception itself can package many information), each Layers define an exception type that defines the mapping relationship between the layer and the layer. My point is that it is simple to be simple to be SIMPLE Butpe SIMPLER.
Re: Error code design! Published: DEC 8, 2004 4:57 PM
Reply Poster: Banq Post article: 3985 / From: Shanghai / Registration time: 2002-08 My personal experience is: there is a DTO abstraction in the web layer and EJB layers, with a setError field, when the web layer is transmitted in the background When the DTO object, EJB Write the error code string to setError, the Web gets the result from the DTO, extracts the Error code, and will be handled by the Struts error mechanism. For example, in the application.propx of Struts, there is a prompt: error.create.name = Create a user error. In the catch's CREATENAME method of the EJB, I am: setError (constants.e_c_n); where constants.e_c_n is "error.create.name". The front desk Struts uses the Error code, GetError () directly displays the error information. This can implement multilingual error display. Program processing also compares template (foolified).
