Repository navigation
Delete NotSufficientlySupportedException in v3: an unsupported operation returns null #1569
Description
Queued from #1559 (comment): in v3, NotSufficientlySupportedException is deleted and every unsupported operation returns null.
On master (882c1eb9) it is thrown at 12 places and caught at none, and 15 lines of the tests name it:
ToSymPy(6):argmax,argmin, the quantifiers, an indexed union or intersection over a set SymPy cannot list, an application of an undeclared lambda, and the nodes SymPy has no counterpart for.- Matrix serialisation (2):
SerializeandDeserialize, both always. Solve(3): an inequality the statement solver cannot read (Solvers.Definition.cs), a system of equations past its budget (EquationSolver.InSolveSystem), and a piecewise Boolean statement (BooleanAnalyticalSolver).- The special set of a domain (1):
Domain.Any, or a value from outside the enum.
Docs/Usage/Exceptions.md, Docs/Contributing/NodeContract.md and Docs/Usage/Comparison.md describe it and change with it.
Activity
Happypig375 commentedon Sep 30, 2026
In fact all exception types require a review to see if null-returns or returning a union type (think how you'd do it in functional languages like F#) is cleaner for the API shape instead. Presumably all exceptions are to be replaced with proper return types.
Rafael-SOWNet commentedon Sep 30, 2026
Recorded in #1019 item 13: every exception type is to be reviewed for a null or union return, and the ones it listed as staying exceptions (misuse,
AngouriBugException, the parse exceptions) are now candidates for that review, not exemptions.Happypig375 commentedon Sep 30, 2026
Maybe there are some exceptions (haha) that throwing would still be appropriate: the implicit string parsing for example to declare an entity easily with a string. But there doesn't seem to be more cases where this is wanted.
Rafael-SOWNet commentedon Sep 30, 2026
Recorded in #1019 item 13: the implicit conversion from a string keeps throwing.