- Home
- Tutorials
- Flash
- Intermediate
- Flash Remoting & FlashCom Server
Handling errors
Copyright © 2004 O'Reilly Media, Inc. All Rights Reserved. |  |
| This content is excerpted from the above-named O'Reilly publication, with permission, by agreement with ActionScript.org. | |
Up to this point, we have assumed that everything will always work, which is unfortunately not the case during either development or production. When relying on an external resource to perform processing, the external resource may change or be unavailable, or parameters that were once valid may no longer be valid. Remoting has the capability to alert the client that something has gone wrong and provide additional details that may help determine what has happened.
If a remote server fails to process a call, it returns an error
object and invokes a status method (in this
case, "status" is a euphemism for
"error"). Regardless of how you
handle the error message, which depends on how you defined your
response object, Flash Remoting always passes a single error object
to the status method. The error object returned by the remote server
includes level and description
properties specifying the error severity and an explanation of why
the server couldn't perform the request. The values
of these properties, while not always completely accurate, are
invaluable in debugging the error.
If you use the methodname_Result( ) approach for your responder, you should specify a methodname_Status( ) function to catch any errors. There are still yet other options, however. The NetServices package dispatches the onStatus error from a remote call in the following order, stopping when it finds an appropriate handler:
First, it looks for a function named methodname_Status( ) defined on the response object or the current timeline.
Otherwise, if a response object with an onStatus( ) method was specified in the call to getService( ), status errors are sent to that onStatus( ) method. (If you pass a response object with an onResult( ) method as the first parameter to the remote method call, an onStatus( ) method is called only if it is attached directly to the response object. If you pass such a response object to each remote method call, the handlers cited in Steps 3 and 4 are never called.)
Otherwise, the _root.onStatus( ) method, if any, is used.
Otherwise, the _global.System.onStatus( ) method, if any, is used.
Otherwise, if the movie is playing in the authoring environment, results are sent to the Output window.
Otherwise, the results are lost.
In many situations, there is not any meaningful action that the client can take to correct the problem at runtime. Depending on the application, you may simply report the error to the user, stating that the remote service is unavailable. In other cases, the error can be corrected by adjusting the parameters that are sent to the remote server. At other times, intermittent connection errors, such as with HTTP calls, can be solved by simply trying again. When an HTTP call fails in Breeze Live, the application typically retries it five times at 1-second intervals. (You should avoid being so aggressive in retrying as to create an inadvertent denial-of-service attack.)
All the basic ActionScript datatypes can be passed through AMF with remoting. A remote server can interact with the passed datatype using its native syntax. The actual translation of datatypes varies by remoting implementation; consult Flash Remoting: The Definitive Guide or your remoting gateway documentation to see how each datatype is deserialized on the server. Passing most ActionScript datatypes requires no configuration or additional code; all you need to do is pass the variable as a parameter to the remote method.
You can also send and retrieve an instance of a custom class with Flash Remoting. Some remoting implementations allow you to have a definition for the class available on the server side and have the class restored as an instance of the server-side class. Likewise, you can receive an instance of a custom class and have it constructed back to an instance of the class available in the client code.
Passing an instance of a custom class is a useful tool. Using methods
instead of accessing properties directly is an excellent way to hide
the internal implementation of the data and is the most flexible
approach in case the data structure changes in the future. Any code
that accesses the data will not need to be modified if it uses the
methods to access the data (assuming the method definitions are
updated correctly). You could also define methods that create unique
displays of the data. For example, you could have a
firstName and lastName property
in the data and have a method that returns the full name as follows:
DataClass.prototype.getName = function ( ) {
return this.firstName + " " + this.lastName;
};
The getName( ) method simply returns the
firstName and lastName
properties joined together with a space. Using such a method is
easier than joining the two properties together every time the name
needs to be displayed or used in this format.
Having the custom class defined does not automatically deserialize the passed object as an instance of the class. In a FlashCom application, you also need to register the class using application.registerClass( ):
application.registerClass(className, constructor);
The className parameter is the name of the
class as a string. The constructor
property is the physical function that should be used to reconstruct
the instance of the class object.
function myClass ( ) {}
application.registerClass("myClass", myClass);
This example will register the class myClass as a
class that can be deserialized.
