[Core] Fix Quantity construction with value as double + unit as string

[0penBrain]

https://forum.freecadweb.org/viewtopic.php?f=3&t=64261&start=20#p552178

This PR fixes construction of quantity with 'Quantity(double, QString)' that because of Unit implicit conversion leads to weird :
Quantity(1.0, QStringLiteral("m")) ==> "1 mm"

Now :

• Unit(QString) is made explicit so no conversion can implicitly happen. Notice that behavior is unchanged so Unit(QStringLiteral("m")).getUnit() ==> "mm" but this looks correct to me as Unit has internally only unit dimensional awareness (no multiplier awareness)
• Quantity has a dedicated Quantity(double, QString) constructor that tooks into account multiplier induced by unit so now Quantity(1.0, QStringLiteral("m")) ==> "1 m"

This PR has impact on #5232 so should be merged or rejected first.

I checked that currently nowhere in the master was used the problematic 'Quantity(double, QString)' construction and that's fine (no current use).

[freecadci]

for feature branch PR_5235. Pipeline 425425698 was triggered at 2a4452f. All CI branches and pipelines.

[freecadci]

for feature branch PR_5235. Pipeline 427881618 was triggered at 3f41c0b. All CI branches and pipelines.

[wwmayer]

catch(...) should be replaced with catch(const Base::Exception&)

[wwmayer]

Merged this PR as 2fef77e with the above mentioned change.
fb84f71 extends the Python wrapper and adds some unit tests

[0penBrain]

catch(...) should be replaced with catch(const Base::Exception&)

I (stupidly) copied it from

FreeCAD/src/Base/Unit.cpp

Line 110 in fb84f71

catch (...) {

Should it be changed there also ?
Can you give some more explanation on this in order to improve next contributions ?

ANyway thx for merging, will now update #5232 accordingly and unleash it ;)

[wwmayer]

Should it be changed there also ?

Yes. Thanks for the hint. Searching for catch(...) in the current code base shows that it's used too often and this should be reworked where not appropriate.

Can you give some more explanation on this in order to improve next contributions ?

In many articles about coding guidelines it's considered bad practice to always handle exceptions with catch(...) because it may hide a deeper problem. The expression parser throws a Base::Exception (*) in case of a failure and only this should be handled. In case any other exception type is thrown the catch(...) swallows it and since it's not reported one would not even notice that there is a problem somewhere.

(*) IIRC the parser in the past has thrown Base::Exception but now it throws Base::ParserError. So, in the corresponding catch handles we should use Base::ParserError instead.

[0penBrain]

@wmayer Thx for details