Adobe announced Open Screen Project which kicks off May 1. Pretty influential group of leaders come together to create a consistent runtime environment that removes barrier of delivery of content and applications to everything.
When you have a stack that has similar technologies (J2EE) it is very easy to report errors/exceptions across different layers. But, this very soon becomes a very interesting and nail biting issue across platforms.
A few days back one of my module leads came up to me and said that they have not been able to understand what are the exceptions that are being raised on J2EE server. Hence, the client Flex in our case can not report the root cause to the user. This is now becoming a mess as we need to handle usability and a better feedback to the user appropriately.
I started to think that there has to be some way to find that out and finally after a few hours of reading through the documentation I know how to solve the problem. But, before I take a deep dive into that solution i will quickly run through my architecture so that you understand in what constraints have I tried to solve the problem.
On the back-end I have Spring beans which are sitting in JBoss container. On the client I am using Flex 3 and Remote Objects to connect over AMF to Java. But, channel is not an issue here.
Java Code
One of the very common patterns that I have been using for Exceptions is to define custom exceptions that represent business errors. Example: If user is requesting an object but that that object is no longer a valid object, then always throw an exception named “ObjectNotFoundException”. The message should be such that it carries the information of the object requested by the user. In this example, I will be using a very basic form of a custom exception.
package com.exceptions;
public class InvalidOperationException extends Exception
{
private String msg;
public NumberFormatException(String message)
{
this.msg = message;
}
public String getMsg()
{
return this.msg;
}
}
This is an custom exception that when a user creates needs to pass a message that should be stored. Note that how you handle exceptions on the server is not in scope of this article, but one day I will post my recommended practices of managing Exceptions.
This code snippet shows how do I raise the exception.
public void doOperation() throws InvalidOperationException
{
// Will throw an exception
try
{
int a = 2 / 0;
}
catch(Exception ex)
{
throw new InvalidOperationException(“this is some error I should get in Flex.”);}
}
Flex Code
If you use RemoteObjects then you can make calls to remote destinations and add responders to the AsyncObject. The responder allows you to provide a fault handler which should be coded as:
public function fault(e:Object):void
{
var evt:FaultEvent = e as FaultEvent;
var errorMessage:ErrorMessage = evt.message as ErrorMessage;
Alert.show(“message : ” + errorMessage.rootCause.msg);
}
Note that I am using the mx.messaging.messages.ErrorMessage class. When you raise an exception on the back-end that exception is placed in the root-cause of the ErrorMessage object. Out of the box if you try to access the rootCause.message property, you will get the some default message. But, this is not so much helpful. Many a times, you may need things like the stack trace or additional information about the error which then is passed along in the object as the property that you have defined in the code above “msg”.
My sample here only takes care of checked exceptions. There is still a conversation/thread that I am working on to understand how can I trap the un-checked exceptions and pass along additional context to the Flex client. But, this is a back-burner because I believe in code that does not raised any un-checked exceptions.
Bingo!! Have fun with errors.