Missing check for @Duck void procedures

[jlmaddox]

There is at least one missing check in proc right now, but also possibly others. We need to look for places with missing checks and then create those checks. As an example, using @Duck on a procedure returning void is not presently checked and breaks the processor.

Additionally, it would be a good idea to go through the code searching for switch statements who have an error case and have them throw RuntimeException for unreachable/unrecoverable cases. For example in util.MessageShape.getKindAnnotation.

[dwtj]

I agree that this is a missing check. Over on my fork, as part of commit 8ecb85c I've added a compile test to check for this case. The test results in an exception:

java.lang.IllegalArgumentException: Procedure labelled with @Duck is unduckable.

coming from org.paninij.proc.util.MessageShape:83.

I forget the details right now, but aren't there other cases where MessageShape determines that a procedure's shape is invalid. This makes me think that we don't just want a check that checks for when a void procedure has @duck on it; we want a check that will tell the user about any of the invalid cases detected by MessageShape.

[dwtj]

Note that I've renamed the title of this issue to focus its scope to just this one missing check.

[dwtj]

@jlmaddox, I agree that it would be good to identify switch cases with error cases and to loudly throw errors from them. Ought we to make a separate issue for that? It looks like you made a branch on your fork related to this. What's the status?

[jlmaddox]

In regards to the branch 144b on my fork, I have covered all the possibilities I can find. However, I noticed that some of the switch cases that were already covered throw IllegalArgumentException despite the function not taking an argument (error would be due to the argument passed to the constructor instead). I was thinking of either changing them to IllegalStateExceptions or RuntimeExceptions but I wasn't sure which would be the better fit.

[dwtj]

Yes, either of those exceptions would probably be a better fit. I haven't looked at the code, but is it possible/easy/sensible to just make the determination of an invalid argument at construction-time? That way we could throw the exception from the constructor.