Exceptions

Here we will cover using AngouriMath in real projects, where it is important to provide safety and security.

Exceptions

Every exception thrown by AngouriMath is derived from AngouriMathBaseException. Although we still recommend catching particular exceptions rather than catching this one, it is important to be able to catch all exceptions thrown by a library.

Under it there are three groups:

MathSException and its descendants say that the input was not something the library can work with — CannotEvalException when an expression cannot be reduced to the type asked for, NumberCastException when a number does not fit the primitive it is cast to, UncompilableNodeException when a node has no compiled form, WrongNumberOfArgumentsException, BadMatrixShapeException, and others. ParseException is a MathSException too, with UnrecognizedFunctionParseException, MissingOperatorParseException, UnhandledParseException and the rest under it.

NotSufficientlySupportedException is thrown where the library knows the answer exists and has no method for it — a cubic inequality, for instance. It marks a gap in coverage, so it is worth opening a feature request if you meet one, but it is not a defect.

AngouriBugException is thrown when an internal error occured in AngouriMath. It is almost certainly that the error happened on AM's side, so we ask you to report about it to the official repository if it happens. It will help us fix it quickly and release an update sooner.

The distinction between the last two matters, and it changed in 2.0. AngouriBugException used to be thrown for known gaps as well, so a reader was asked to file a bug for something nobody had written yet; those now throw NotSufficientlySupportedException. FutureReleaseException, which 2.0 removed, was a third spelling of the same thing.

All exceptions are documented, so if encountered an unknown one, we recommend you checking it on the Almanac or documentation in-code.