In our previous posts in this series, we talked about how an MboSet is a collection of Mbo objects. In this article, we’ll analyze the different types of exceptions that can be thrown and how each can be utilized. Most methods that can be called through the Business Components can throw either a RemoteException and/or an MXException. A RemoteException is thrown by the Java RMI system when an error occurs during remote communication. The exact nature of the error may be determined by checking the Exception object’s class – which may be one of seventeen subclasses of RemoteException. For more details of these exceptions, refer to the documentation in the Java Development Kit. The MXException is similar to the RemoteException in that the MXException is a super class for all related exceptions. The actual exceptions thrown will be instances of one of the following subclasses:

• This is usually a fatal error from which the client cannot recover. It is usually a problem with either the server configuration or the database configuration. Examples of errors causing this exception are “Out of Memory on Server” or a SQL error. Two subclasses of this class have also been introduced:
  • Thrown when a client or server asks for a Mbo that is not known to the system. This is a fatal error that normally points to a bug in the system or an incorrectly configured data dictionary.
  • Thrown when the server, which should have an object running, does not respond. This is usually caused by an incorrect configuration of the remote configuration file or indicates that the server running the object is unavailable for some reason.
• This is thrown as a result of any of the many possible application-level errors, most of which are not fatal. Such exceptions should be caught by the client and rectified by the logic of the calling program. Examples of reasons why this exception might be thrown are:
  • Trying to set the value of a date attribute to the characters “ABC”.
  • Trying to set the “eqnum” attribute in a WO object to an invalid equipment number.
• Thrown when an attempt is made to set an attribute that is read only or access a method that is currently not available. Methods may be unavailable because of security restrictions or because the object is not currently in the correct state.

More information about an exception can be retrieved by accessing the getMessage(), getErrorGroup() and getErrorKey() methods in the thrown object. These methods constitute two different approaches to identifying the exact cause of the exception. The getMessage() method returns a string which contains a message describing the nature of the error. A message from a nested exception, if there was one, is included here as well. Such messages are intended to be for the benefit of human users. If the intention is that the code itself should handle the recovery from the error, then it is more appropriate to call the other two methods. The error group, returned by getErrorGroup(), usually corresponds to the name of a text file in the RESOURCES\DEFAULTS directory. For example, if the error group is “workorder”, then the textual error description is in resources\default\workorder.txt. The error key, returned by getErrorKey(), identifies an exact line in the text file that describes the error. For example, “addstatus” identifies a line in workorder.txt that has the line of text “addstatus=WorkOrder status cannot be added without a work order”. When the intention is that the code itself should recover from an error, it is far easier to use an error key as input for a condition statement than a message. Note that the error description pointed to by the error key is not necessarily the same as the message returned by getMessage(). Exceptions may also provide greater detail in the form of parameters. These are used to supply information for a more general type of exception. For example, if an attempt is made to call the setValue() method using an invalid attribute name then the error group “system” and the error key “noattribute” would be returned. The exception thrown would also contain as part of its parameter list the name of the attribute that could not be found. To access these parameters, use the methods hasParameters() and getParameters(). An MXException may be thrown as the result of another exception occurring in the system. An example of this is a SQLException. These exceptions are not thrown directly from the methods because it would make method signatures complicated. The programmer can gain access to the nested exception by referencing the member “detail”, which is public, of the thrown exception. A code sample demonstrating the use of an MXException follows:

MXSession s = MXSession.getSession(); s.setHost(hostname); s.setUserName(username); s.setPassword(password); // Display any problems with the connect to the user. try { System.out.println(“Connecting to (” + s.getHost() + “/”+ s.getServer() + “)” ); s.connect(); } catch(MXAccessException ma) { String group = ma.getErrorGroup(); String key = ma.getErrorKey(); System.out.println(“Group : ” + group + “ Key : ” + key + “ Message :” + ma.getMessage()); }