Brief summary of issue / Description of requested feature:

Some (but not all) functions give basic information on failure, for example: which argument is not as expected (if there are multiple arguments) and what would have been expected instead. This should be expanded as best practise for all functions.

Reasons for adding feature:

1. Current best practise seems to be something like "getFontSize: bad argument Profile keyboard navigation #1 type (window name as string expected, got %s!)".
2. Worst practise example is like "createLabel: wrong argument type", where you are expected to give 6 different arguments, and will never learn which one failed or why.
3. Sentence structure of above "best practise" example unfortunately does not seem gramatically perfect or easy to understand for non-English speakers.

Expected result of feature

A good practise seems to consist of following elemets:

• Obviously easy to understand English sentence structure with all needed elements included (e.g. "expected X, got Y")
• number of failed argument (e.g. "Profile keyboard navigation #1")
• meaning of said argument (e.g. "window name")
• expected type of said argument (e.g. "string")
• received type of said argument (added dynamically, e.g. "%s")
• optionally, an indication whether or not said argument was optional (not included in example above)

Ideas for how to solve / implement:

• English sentence structure should be improved for added understandability, like so: "(Optional) Argument Profile keyboard navigation #1 (window name) is of wrong type! Expected string, got %s"
• To avoid uncontrolled growth of different error message styles again, creation of said message should be centralised in a helping function, which only receives details as listed above, and returns the full string. Therefore, future adjustments to sentence structure can be delivered once and for all easily.