org-arl / fjage

Framework for Java and Groovy Agents
https://fjage.readthedocs.io/en/latest/
Other
26 stars 13 forks source link

Errors in parameter getters / setters are not reported #280

Open ettersi opened 1 year ago

ettersi commented 1 year ago

The current implementation does not report errors raised in parameter getter and setters.

I believe the culprit is this generic catch clause here.

notthetup commented 1 year ago

Maybe we should log some kind of errors but not others?

mchitre commented 1 year ago

Values passed in to setters can come from users and can be meaningless in the context. If we insisted on every setter fully validating the inputs, the code would become verbose and less readable. We need a middle ground on how to handle such inputs.

The current implementation is very lax, but simply ignoring errors. The other extreme would be to log stack traces as errors. That feels alarmist and will make logs harder to work with. Perhaps we can log them as single liner warnings?

notthetup commented 1 year ago

Maybe we can ignore data conversion type errors but log other types of errors?

ettersi commented 1 year ago

I'm not following what is the link between validation and error reporting. Are we talking about conversion errors like the user passes a string when an integer is expected? Errors like these should be fairly easy to detect and ignore, like @notthetup suggested. It seems reasonable to me that anything beyond that would qualify as a programming error. Otherwise, you'd e.g. get an error message if you make a programming error in a processrequest(), but you wouldn't get one if you moved exactly the same code to a setter.

mchitre commented 1 year ago

Let's do warnings for conversion errors, and stack traces for other exceptions. And if that gets noisy in the logs then revisit why.