Errors are not descriptive in a easily meaningful way

[raegun2k]

Hi,

I would like to toss in an issue I've long struggled with when using FreeCAD. Specifically that errors make sense if one digs into the Python sourcecode, but not if one is just looking at their CAD model.

To give a specific example:

I created a sketch. Two rectangles, one inside the other. I constrained the outside rectangle dimensionally then I attempted to constrain the wall of the internal rectangle dimensionally to the outside wall(one side of the outside rectangle to have it so that the distance between the two walls would always be a set amount of millimetres. It didn't work, because I was constraining two lines, not points. Okay, fair enough. If that's a limitation/design of the software, not big deal, I can adjust easily as the walls were vertically constrained anyways.

But the error reported was this:

10:39:21 pyException: Traceback (most recent call last): File "<string>", line 1, in <module> <class 'ValueError'>: Datum 5.00 mm for the constraint with index 20 is invalid 10:39:21 Unnamed#Sketch: App.getDocument('Unnamed').getObject('Sketch').setDatum(20,App.Units.Quantity('5.000000 mm'))

What am I, as the engineer working on the sketch, supposed to do with that besides know something went wrong. There are multiple ways that error could be reported that would make it more human/readable. However, a very easy one to correct here would be to adjust this bit:

"Datum 5.00 mm for the constraint with index 20 is invalid"

At the most basic, "index 20" means nothing to me. It's not reflected in the UI, and given the constraint's failure to even get generated,it technically doesn't even exist anymore. Even if it did, let's assume it failed due to an upstream change/formula adjustment. The UI won't tell me what constraint index 20 is.

But the software must know what class of constraint it is, right? Even just changing the output of something like "Datum 5.00 mm for the constraint with index 20 is invalid" to "Datum 5.00 mm for the dimension constraint(index 20) is invalid" would be more useful. And honestly, "datum" could possibly nbe changed to just "value" to make it more accessible but that's just a nitpick on my part.

Basically, the errors still seem better written to troubleshoot the programming of the app versus the creation of objects within it. Obviously the former is important. But the latter is in the end what the software will be used for, isn't it?

So perhaps when writing the exceptions, consideration of "if I knew nothing about how this software works at the pythonic level, would this error help me figure out why my operation failed in the software?" could be factored as part of the workflow.

[raegun2k]

Sorry, opened this in the wrong area by accident