Python call to --processing.run('qgis:fieldcalculator'-- fails to catch divide by zero

[jamesp670]

Describe the bug

The field calculator doesn't appear to catch any kind of syntax or logic error when run through the graphical modeler.

How to Reproduce

1. Go to Processing/Graphical Modeler
2. Click on Algorithms. Search "field ca". Double click Vector table/Field calculator.
3. Configure the calculator to make a new attribute, called 'snam2'.
4. Configure the calculator to divide by zero in the formula. I used '5/0'.
5. Run the model.

QGIS and OS versions

• QGIS dev version fetched just a few days ago.
• OS is Debian 10

The about screen appears completely black with no controls or text.

Additional context

I tried also providing non-existent names for attributes to the attribute() function, as in
: attribute($currentfeature, 'thisAttrDoesNotExist')

I got no error there either, the model runs reporting no error or warning and reports success at the end.

The log reads

": Running Field calculator [2/2]
: Input Parameters:
: { FIELD_LENGTH: 10, FIELD_NAME: 'snam2', FIELD_PRECISION: 3, FIELD_TYPE: 0, FORMULA: '5/0', INPUT: 'memory://MultiLineString?crs=USER:100000&field=fid:long(0,0)&field=cat:in$
: OK. Execution took 10.662 s (1 outputs).
: Model processed OK. Executed 2 algorithms total in 29.284 s.
: Execution completed in 29.33 seconds
" which shows the totally invalid division by zero and the failure of qgis to abort on that error.

I was able to obtain a stack trace as the field calculator ran. I include this to give you an indication of the particular language parser that is not catching errors. I am calling this parser 'QgsExpression' based on the stack trace below.

As you will see, a stack trace follows for a similar and equally problematic field calculation (the calculation here is for formula "attribute($currentfeature, 'attrDoesNotExist')"). Compared to the 5/0 divide by zero case, this one includes an attribute name, and so consequently there are string comparisons being done (unverified assumption) instead of numeric divisions as in my 5/0 example. The general area of the core code base (the QgsExpression parser) is the same in both cases, and both cases result in the error not being caught.

: #0 0x00007fdf8ebf69be in () at /lib/x86_64-linux-gnu/libQt5Core.so.5
: #1 0x00007fdf95fe5ade in QString::compare(QString const&, QString const&, Qt::CaseSensitivity) () at /usr/local/lib/libqgis_core.so.3.15.0
: #2 0x00007fdf963391d4 in QgsFields::lookupField(QString const&) const () at /usr/local/lib/libqgis_core.so.3.15.0
: #3 0x00007fdf9631b18d in QgsFeature::fieldNameIndex(QString const&) const () at /usr/local/lib/libqgis_core.so.3.15.0
: #4 0x00007fdf9631b109 in QgsFeature::attribute(QString const&) const () at /usr/local/lib/libqgis_core.so.3.15.0
: #5 0x00007fdf96013467 in fcnAttribute(QList const&, QgsExpressionContext const*, QgsExpression*, QgsExpressionNodeFunction const*) ()
: at /usr/local/lib/libqgis_core.so.3.15.0
: #6 0x00007fdf96087223 in QgsStaticExpressionFunction::func(QList const&, QgsExpressionContext const*, QgsExpression*, QgsExpressionNodeFunction const*) ()
: at /usr/local/lib/libqgis_core.so.3.15.0
: #7 0x00007fdf96008bfa in QgsExpressionFunction::run(QgsExpressionNode::NodeList*, QgsExpressionContext const*, QgsExpression*, QgsExpressionNodeFunction const*) ()
: at /usr/local/lib/libqgis_core.so.3.15.0
: #8 0x00007fdf95fffae7 in QgsExpressionNodeFunction::evalNode(QgsExpression*, QgsExpressionContext const*) () at /usr/local/lib/libqgis_core.so.3.15.0
: #9 0x00007fdf95ffa435 in QgsExpressionNode::eval(QgsExpression*, QgsExpressionContext const*) () at /usr/local/lib/libqgis_core.so.3.15.0
: #10 0x00007fdf95ffb310 in QgsExpressionNodeBinaryOperator::evalNode(QgsExpression*, QgsExpressionContext const*) () at /usr/local/lib/libqgis_core.so.3.15.0
: #11 0x00007fdf95ffa435 in QgsExpressionNode::eval(QgsExpression*, QgsExpressionContext const*) () at /usr/local/lib/libqgis_core.so.3.15.0
: #12 0x00007fdf95fd848b in QgsExpression::evaluate(QgsExpressionContext const*) () at /usr/local/lib/libqgis_core.so.3.15.0
: #13 0x00007fdf02d58f8f in meth_QgsExpression_evaluate () at /usr/local/share/qgis/python/qgis/_core.so
: #14 0x00007fdf4a976cdb in _PyMethodDef_RawFastCallKeywords () at /lib/x86_64-linux-gnu/libpython3.7m.so.1.0
: #15 0x00007fdf4a977a05 in _PyCFunction_FastCallKeywords () at /lib/x86_64-linux-gnu/libpython3.7m.so.1.0

To be clear, I expect any syntax error in this QgsExpression language's BNF to result in an immediate (preferably compile-time) abort, noisy and final. I also expect divide by zero to be caught (this one is OK to catch at runtime) and to result in an abort, noisy and final. Divide by NULL should result in NULLs I guess (c.f. R's handling of NAs), but divide by zero is immediate death for any program and has been since the FORTRAN days (and since the 18th century in mathematics in general, only in the bad old days was divide by zero considered meaningful in any way).

[troopa81]

It's fixed in master like #37739