How to trap API-level errors

[StephenLead]

I'm seeing an error message in FireBug:

Error: Internal kml parser error.http://serverapi.arcgisonline.com/jsapi/arcgis/?v=3.2compact
Line 34

I'm not worried about fixing this error for the moment - I'd like to know how can I trap the error, so I can report it to the user?

The map has an onLayersAddResult event, which contains an Error handler. Is there a similar map-level error handling event which would trap the above KML parser error?

It seems like the map object needs an onError() event.

Thanks,
Steve

[derekswingley1]

In the results object passed to onLayersAddResult, are you seeing success: false and an error object?

[StephenLead]

Hi Derek,

Let me rephrase to clarify:

There are certain events for which the JS API provides an error handler. Eg, you can listen for a layer's onError event, which fires whenever there is a problem with a specific layer. You can listen for the map's onLayersAddResults event, which fires if there was a problem adding any layer to the map.

Is there a way to trap any generic error which is returned by the map object?

I did something which caused the above-mentioned KML parser error, which triggered a FireBug error message. How can I trap those type of error messages (not specifically the KML parser error, but any error messages which are shown in FireBug?

That way, I can warn users who are not using a debugging plugin that there has been a problem.

Thanks,
Steve

[__Rich_]

You want to catch unhandled exceptions, correct?

(and ideally you're hoping that the API doesn't just 'swallow' these thus preventing them propagating to your code)

[StephenLead]

You want to catch unhandled exceptions, correct?

(and ideally you're hoping that the API doesn't just 'swallow' these thus preventing them propagating to your code)

Hi Rich,

Yep, that's what I meant (and wish I could have said so succinctly).

Steve

[__Rich_]

For any call stacks that you initiate then I guess standard try/catch should work, depending on my previous post i.e. it's no use if the exception isn't allowed to propagate to your catch!  (usual best practices apply)

For call stacks initiated from within the API is a different matter...hopefully one of the team can give us an insight into the approach they have employed...

[StephenLead]

For any call stacks that you initiate then I guess standard try/catch should work

Thanks, I'll give that a go. In some cases though these errors may originate from run-time events which I can't predict now, which is why I'm hoping for a map-level onError event.

Cheers,
Steve