Flex Error #1085: The element type ‘p’ must be terminated by the matching end-tag

Even though I have this blog set up for quite a while the first post managed to fail showing up for some reasons… I finally had some time and decided to dedicate this first post to one fo the Flex errors e.g. Error #1085.

I have been doing some consultancy Flex work lately which involved talking to a .Net web service as back-end. Inherited code-base lack of both technical or business documentation, you know the drill…  However hings were progressing really well, so it happened that one of the tasks required to perform CRUD operations for a certain table. The service was automatically generated by the Flash Builder, the VO was in place classes that triggered and carried out the save were wired so I proceeded with the call. Then surprise surprise: i get the Error #1085: The element type “p” must be terminated by the matching end-tag on the fault on service’ fault handler. Since I wasn’t processing the results as XML but as typed objects it seemed really odd.

Goggled for the error and most of the stuff out there points to the fact the the returned XML is not well formatted which was not the case here. After failing to figure it out on my own, I asked the back-end guys to perform a step by step debugging. Call went on fine through the .Net layers towards the DB were it was dismissed due to the fact that one of the mandatory fields was empty. To be more precise the persisted object had a list of assets associated to it which could not be empty. Since no one knew about this and you and the wire-frames for the view indicated the asset list as read only (later we found out it was suppose to be filled as a result of other business processes), I went on and only filled in the fields marked as mandatory in the wire-frames. Obviously the VO ended up with a null Array collection which trigger the DB failure. Adding a single item fixed the issue and the WS call went through without any other problems.

So the moral of the story is that it never hurts to have a more user friendly error thrown by your service, as it also never hurts to inquire for all the mandatory fields before you run your first service call. I decided put these line out here in case anyone else bumps into this issue maybe it might help them.

Leave a Reply

Your email address will not be published. Required fields are marked *

*