[
https://issues.apache.org/jira/browse/METRON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688120#comment-15688120
]
ASF GitHub Bot commented on METRON-490:
---------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/301
I totally forgot about this. Looking over this again, I am a little
ambivalent about this PR.
I did as an experiment. I thought it would be cool, if parameter handling
could be taken care of auto-magically. I wanted to just specify the parameters
that I need via the annotation and have some shared logic perform parameter
handling and validation, along with enhancing the docs. Seems more DRY-ish and
all that.
As this stands, I don't think it is very useful. Different functions want
to handle required params in different ways. Sometimes an exception is thrown,
sometime a value is returned like NaN, etc. This doesn't give you any
flexibility in how to respond to missing params. There are probably a few
other things that need to be covered before this is close to being useful.
I would be interested in opinions on this though. Maybe with input from
others this could become useful. But right now, I am a -1 on this.
> Stellar - Validation of Required Parameters
> -------------------------------------------
>
> Key: METRON-490
> URL: https://issues.apache.org/jira/browse/METRON-490
> Project: Metron
> Issue Type: Bug
> Reporter: Nick Allen
> Assignee: Nick Allen
> Fix For: 0.3.0
>
>
> Currently, each Stellar function handles validation of required function
> parameters in its own way. In some cases, we have functions that throw an
> IndexOutOfBoundsException, in other cases the function will produce its own
> error message and exception.
> There needs to be a standard mechanism to validate required function
> parameters. This mechanism should handle missing parameters gracefully and
> provide an error message that makes sense to a user.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
