CesiumGS / cesium

An open-source JavaScript library for world-class 3D globes and maps :earth_americas:
https://cesium.com/cesiumjs/
Apache License 2.0
12.62k stars 3.42k forks source link

Have better errors for issues with KML files #5436

Open cguldner opened 7 years ago

cguldner commented 7 years ago

I think there needs to be more helpful errors when a KML file fails to load. For example, I spent a long time trying to debug this error when adding a KML file to Cesium

Error processing drag and drop DemoKML.kml:RuntimeError: Invalid XMLHttpRequest response type.
Error
    at new t (http://localhost:3000/lib/Cesium.js:517:29185)
    at XMLHttpRequest.f.onload (http://localhost:3000/lib/Cesium.js:520:29246)

I tried with the unminified Cesium.js file, and it just pointed me to the place where the error was raised, not giving me any insight into what was wrong. I figured it was a problem with a link somewhere, since it was making an HTML request. Only after looking at it for a couple hours did I finally figure out the issue. I had my styleUrls with spaces around it in my Placemarks

<!-- Style Definition -->
<Style id="RedLine">
    ....
</Style>

<styleUrl> #RedLine </styleUrl>

I feel like the Cesium file easily could have given me a much more descriptive error. Maybe not specifically where the error was happening, but at least there was an undefined style referenced

thw0rted commented 6 years ago

The issue is that Cesium uses a heuristic to determine how to parse the styleurl and it's failing with the leading/trailing space, as you identified. The immediate fix is probably to trim() the URL before picking it apart, but the larger issue is that there are a lot of network calls for different reasons and the errors usually bubble up several levels before being handled, so you don't have the context for which call failed (or why it was made) by the time it shows up in the console.

It would be helpful if some debugging messages were inserted in the middle of that exception chain, along the lines of

.otherwise(function(error){
  console.log("Failed to load external style '" + uri + "'", error);
  return when.reject(error);
}

Likewise, various loading / parsing failures just log the XHR error or XML parser output directly without including a description of what was being done when the failure occurred. It's much more useful to say console.log("Failed to load document from NetworkLink", error); than just console.log(error);.