Invalid boolean and number values of a bean property are silently converted instead of failing

A macro parameter of type boolean or int accepts any value. A value that does not convert is replaced without an error: an unknown boolean becomes false and an invalid number becomes 0. The macro then runs with a value the user never typed, and nothing tells them the value was wrong.

Steps to reproduce

1. Edit a page with the wiki editor.
2. Add {{toc numbered="maybe"/}} and {{toc depth="abc"/}} on a page with headings.
3. Save and view the page.

Expected

Both macros fail with a message saying that the value of the parameter cannot be converted.

Actual

• The first table of contents renders unnumbered, as if numbered was false.
• The second fails with "Failed to validate bean: [must be greater than or equal to 1]": abc was converted to 0, and only the @Min(1) constraint stopped it.

The WYSIWYG usability audit of the macros found the same on most of the 67 macros reviewed, for example wiki="abc" on the HTML macro, status="maybe" on the message macros, readOnly="maybe" on documentTree, which makes the tree editable, and count="abc" on notifications, which loops forever, see XWIKI-25412.

Lead

ConvertUtilsConverter registers the throwing BeanUtils converters in initialize(), on BeanUtilsBean.getInstance(), so that a failed conversion raises an error rather than returning a default value. That instance is kept per context class loader, so the conversions run under another context class loader may use the lenient default converters. The tests of ConvertUtilsConverter do not cover an invalid boolean or number.