View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004040||PartDesign||Bug||public||2019-06-27 10:26||2019-06-28 06:06|
|Summary||0004040: lack of error message on failing to pad sketch|
|Description||There is clearly some test or operation which is failing here but nothing is output at a stage where it can be useful. |
Having effectively broken the outline in the sketch, no error is produce on closing when the pad attempts to recompute.
Errors should be adequately trapped and useful output provided as to what failed, at a level where that information is available.
Similarly, on attempting to change the length of the pad in this condition, a window with the text "Error! is really not that informative.
This could be handled in a way which is more informative to the user.
|Steps To Reproduce||Create a sketch with closed form.|
pad from sketch.
edit sketch to no longer be a closed form.
Note exclamation on pad: try to find some error output, explaining the error.
The attached file shows the state of a model after inadvertently leaving a sketch without a closed form ( the construction lines masked that there was a missing line to close the loop ).
On exiting sketch editor, the pad element named base-block showed an exclamation mark but there was no output in report window nor on the console showing that an error had occurred.
Subsequent attempts to edit the pad produce a tiny window with the text "Error!". As before, nothing more is produced.
|Additional Information||OS: Linux (LXDE/LXDE)|
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.17119 (Git)
Build type: Release
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)
|Tags||No tags attached.|
housing-error.FCStd (49,989 bytes)
TheMarkster has noticed that the presence of the path elements seems to be eating the error context, leading to the terse and unhelpful "Error!".
I have confirmed that the presence of the jobs do not affect this but at least one path in either job will trigger this bug. With no paths present there is a proper error msg which reports "failed-to-validate-broken-face".
Presumably the change to pad triggers a recompute of the paths and the error context is lost. It seems that this should be trapped and reported before attempting a recompute ( which will be futile anyway if the base pad object is broken).