It would be nice if FreeCAD prints the full traceback of a workbench that not loaded correctly. I think directly writing the full traceback to the report view would be the best option. Currently there is only this information available: "During initialization the error .... occured".
What about changing this line to traceback.print_tb. The information currently given, is often not enough to find the error.
ps.: I just tried this, and it seems that it needs a bit more to get the full traceback...
print full traceback when Init.py / InitGui.py fails to load
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: print full traceback when Init.py / InitGui.py fails to load
No changes needed because this line writes it out as a log message. So, you either switch on the log mode for the report window or look at the console output or look at the FreeCAD.log file.
And with "During initialization the error .... occurred". I was always successful in finding the cause of the problem.
And with "During initialization the error .... occurred". I was always successful in finding the cause of the problem.
Re: print full traceback when Init.py / InitGui.py fails to load
True, the log message has more information. Never looked into this.No changes needed because this line writes it out as a log message.
Sometimes a traceback is nice to have. II don't see the reason why we should hide it in the error message.And with "During initialization the error .... occurred". I was always successful in finding the cause of the problem.
Re: print full traceback when Init.py / InitGui.py fails to load
Example where the single message wouldn't be enough to find the problem.
Re: print full traceback when Init.py / InitGui.py fails to load
Same problem with the function Initialize of a workbench:
If there would be added the traceback I would know where to look for the map.
Code: Select all
<unknown exception traceback><class 'TypeError'>: 'map' object is not subscriptable
InvoluteGear: 'map' object is not subscriptable
Re: print full traceback when Init.py / InitGui.py fails to load
Maybe it would be appropriate to have both the long traceback and the (current) summary as options, by making the behaviour conditional on it being a Debug or Release build? -Ian-
Re: print full traceback when Init.py / InitGui.py fails to load
For python programming it would be quite useful to have better traceback outputs. Another example:
while at startup the traceback is included in the logfile, the traceback on workbench.initialize is totally suppressed. I think we should handle this in a consistent way. Python-users are used to have the traceback added to the exception message. So I would vote for python consistency in FreeCAD.
Are there any reasons for printing the traceback in the log-file? I am fine with that, but would prefer a bold red message
(rises in workbench.initialize())libicui18n.so.58: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
<unknown exception traceback>
while at startup the traceback is included in the logfile, the traceback on workbench.initialize is totally suppressed. I think we should handle this in a consistent way. Python-users are used to have the traceback added to the exception message. So I would vote for python consistency in FreeCAD.
Are there any reasons for printing the traceback in the log-file? I am fine with that, but would prefer a bold red message
Re: print full traceback when Init.py / InitGui.py fails to load
Just tried this with python2 and there workbench.initialize() prints a full traceback... So this is more related to python3.I wrote:while at startup the traceback is included in the logfile, the traceback on workbench.initialize is totally suppressed. I think we should handle this in a consistent way. Python-users are used to have the traceback added to the exception message. So I would vote for python consistency in FreeCAD.