Posted in Flex | Posted on 12-04-2006 | 2,553 views
After my last post on a simple error handler for ColdFusion, I was asked how I would do the same in Flex 2. Keep in mind I'm still new to all this - so I'm sure (and I'm counting on!) my readers to correct me - but here is my answer to that question.
First and foremost - and this applies to any software program, you need to decide what should happen when something goes wrong. In general you can divide problems into two categories:
- "Oh Crap" Errors. These are errors that are severe. They can be things like a bad database connection or the inability to read the file system. In general the reaction to this type of problem is to halt everything, hence the "Oh Crap" term. In this situation you basically stop the entire application from being used until the problem is corrected.
- "No Big Deal" Errors. These are errors of a not-so-critical nature. For example, the ColdFusion Portal aggregates a few RSS feeds. If those feeds go down, I display a simple error message, but I certainly don't bring down the entire application. It wouldn't make sense.
So not every error can be put into one of these categories, but you get the general idea. My point here is that nothing Flex specific will change how you decide to deal with errors.
So with all that behind me - the actual error handling is pretty simple. First I define my remote object:
Next I define a method and add a fault handler:
Notice the fault= part. This tells Flex what to do when something goes wrong with the getData call. If it isn't obvious - you can set a different fault action for each method, and one at the remoteObject level to cover them all.
Now that you've told Flex what to do with the error, here is some very simple code to do something with it:
2 Alert.show(fault.faultCode,"faultCode");
3 Alert.show(fault.faultDetail,"faultDetail");
4 Alert.show(fault.faultString,"faultString");
5}
All I did was alert various parts of the Fault object. I could have checked for the various values and actually handled them, but this gives you the idea. Question: How would you handle the "Oh Crap" version? Seems like it would make sense to either use a ViewStack and switch to a page with the error message. Or perhaps simply push the user to an HTML page with the same message.
I included a zip of the files I used to test the code above. The CFC it calls tries to use a datasource that doesn't exist so it should throw an error for you.
One thing I've found helpful is using the ServiceLocator / Business Delegate patterns from Cairngorm. It'll let you more dynamically handle errors by "wrapping" the existence of the remote object in a delegate, letting you have different delegates for different contexts, doing different things for faults on the same remote method.
On the UI side, I'm generally showing people Alerts that contain a (human friendly!) error message and the option to try again - which is something else the Command/Delegate patterns make pretty easy.
It's important to note that the fault handler is really only useful when things really go kablammo.. If you are doing proper exception handling in your back end you'll need to be able to report those issues back to the calling application.