Provide more information in exceptions

[Paul2708]

Is your feature request related to a problem? Please describe.
I want to give a detailed description about occurring exceptions.
Atm the exception holds its meta data in the exception message.

Describe the solution you'd like
You could add getter in the specific exceptions. E.g. int getFoundArguments() and int getExcpectedArguments() in ArgumentException.

[JohnnyJayJay]

Good idea, for that matter it should also be considered to separate the exceptions thrown by CommandArguments when no further argument is available and the exception thrown by MappingProcessor when there are still arguments left, because when CommandArguments throws an ArgumentException, it is not aware of the amount of expected and found arguments respectively. Maybe it could throw a separate exception that is caught by the framework and the framework in turn throws a proper ArgumentException with the given information.

Alternatively, the ArgumentException could be made mutable so that information like the expected and found arguments can be attached later.

The other question is how to integrate this with the standard library flag arguments. While they technically use the same argument APIs, numbers like "expected" and "found" arguments might not be useful to handle missing flag values. It might actually be best to unify ArgumentException and MappingProcessException in some way within the bind framework.

[JohnnyJayJay]

There is one problem that arises when speaking about "expected" arguments though: Since it is not defined how arguments are consumed by the interceptors and mappers, you can't say how many arguments are expected midway through parsing. The only thing you can ever really tell for sure is whether there are too many arguments or whether an argument is missing.

What I am currently considering is implementing some sort of cursor that shows you where an argument is expected.

The ArgumentException could then be passed the CommandArguments instance which would give you access to the original arguments, the remaining arguments and the current argument cursor.

On the same note, some of the exception messages should also be adjusted to be useful to end users.

[Paul2708]

I want to note that i just came across two more exceptions:

• MissingContextException: Object getMissingKey()
• MappingProcessException: String getArgument() and Class<?> getMappedClass()

[JohnnyJayJay]

I'd probably provide a Type rather than a Class for more information in MappingProcessException, but good suggestion. Will implement it in accordance with #3 .