Replace ValidityProblem usage with InvalidOpExceptions#88
Conversation
gselzer
force-pushed
the
scijava/scijava-ops-engine/replace-validity-problem
branch
from
4506778 to
77d0951
Compare
|
This will close scijava/scijava#105 |
@gselzer so the concern I had was using raw string values as a substitute for testing for the type of failure. If the error's message changes for any reason the test will fail. What you're testing is that the error message is consistent, but what you actually want to test is that the type of error is consistent. Subclassing and checking the subclass in the test would probably be the most Java-correct thing to do. Using constants, like in BaseOpHints, instead of raw strings in the test expected values would be an acceptable improvement. |
gselzer
force-pushed
the
scijava/scijava-ops-engine/replace-validity-problem
branch
from
a20ac75 to
451fa93
Compare
|
@hinerm I made a bunch of subclasses, let me know what you think of this. |
gselzer
force-pushed
the
scijava/scijava-ops-engine/replace-validity-problem
branch
12 times, most recently
from
748da4f to
a69b7b4
Compare
gselzer
force-pushed
the
scijava/scijava-ops-engine/replace-validity-problem
branch
from
a69b7b4 to
44348e9
Compare
gselzer
deleted the
scijava/scijava-ops-engine/replace-validity-problem
branch
2 participants
This PR makes Ops throw
InvalidOpExceptions instead ofValidityExceptions - this creates a simpler structure for conveying issues with Op configuration/declaration to Op developers. It also provides a suite of tests to ensure invalid Ops are beingTODO: @hinerm - you said here that you do not want string comparison - can you elaborate on why? Would you prefer that we subclass
InvalidOpExceptionfor each of the reasons of failure? There would be a lot of subclasses with pretty detailed names, if you'd prefer that...