More Explicit Error Messages

[TJ_Houle]

We have been working to implement the Utility Network (with the 2020 UPDM data model) in a Postgres database. Throughout the process, we've gotten many errors similar to this:

There was no real guidance on what was wrong or how to fix it. We spent two days or so looking into different possibilities. As a part of that work, we exported the asset package to a file geodatabase (Postgres) and were able to see what the issue was in less than 15 minutes; as show in the screen shot below.

Would it be possible to provide more detailed information in the errors that are provided through the Pro interface?

[JohnBendix]

Looking at your errors...Your defiantly have issues with "nulls" in your assettype. Which I don't think the UN will like. The UN has a constraint on that column.
As far as using pro to get more info..?? The best thing would be go from the asset package to a filegeodb and see how stuff validates and errors out. This is as long as your asset package is complete.

[TJ_Houle]

Thanks John, that's exactly what we did. But wouldn't it be nice if we didn't have to? Why not provide the same errors we get from the file geodatabase in the system we are actually using?

[MelissaJarman]

After reviewing the details of this Idea, I would recommend that you contact support services team to start providing a reproducible case to log a defect. This type of situation would be best handled by logging a software defect for better error messaging, while ideas are more in the lines of an enhancement. 

I recommend if you have not already, provide a reproducible case where the error is not being properly displayed when using the utility network in an enterprise geodatabase. eg: The Update Subnetwork process is not identifying there is an issue with the underlying network features. 

Please feel free to reach out to me if you have problems contacting our support staff. 

[TJ_Houle]

Hi Melissa-

The Esri folks have been great when we chat with them, but I think what I am asking for is better error reporting so we can do more troubleshooting on our side. It becomes really difficult if every time we get an issue we have to contact support and wait for response, especially when the detailed information is available and could be provided out of the box by Esri.  Does that make sense?

The example I provided is a specific instance, but there are many more in the same category. Rather than a solution for the above error, I am asking for a more global one. Here's several more samples from errors we've encountered just this week:

To be clear, we have resolved both of the errors in the above screen shots, and we don't need help with them any longer- these are just samples.

[JamesWright9]

Complete agree with TJ, the error reporting in the UN is far from desirable.

For example, the error he demonstrated last "The dataset was not found". What dataset?

I see lots of errors like this. For example when updating subnetworks you get the error "A dirty area was found". What dirty area? What if I have 10,000. How do I figure out which one it cared about? There are a few examples were good errors are reporting, but more often than not they are useless.

Overall there are far too many of these to outline. General point is, provide details in the errors please.

[KrisFoster1]

To add more to this topic, here are a couple of errors I received doing edits from a stand alone app.   The errors themselves are not very helpful as it is, since they don't actually describe what field or what data is bad, but to make matters worse, these errors do not fire on Row.Store() call, but rather on the ApplyEdits() call.  So when that ApplyEdits() call is wrapping up hundreds of edits, you can't even determine which row it failed on.  This makes the determination of exactly what has failed extremely difficult and cumbersome.

Error One:

Error Two: