Error handling in an experiment
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EBSD-Image |
Fix Released
|
High
|
Philippe Pinard |
Bug Description
The new EBSD multimap now has a default map to save error that may occur during the execution of operations. This map is called ErrorMap. It is a ByteMap with an additional array to track the error message assigned to the values of the pixel. For example:
* 1: Error loading diffraction pattern
* 2: Not enough bands
* etc.
Operation can register errors inside the map so only a pixel value is only associated to one type of error.
The question is now how to integrate this inside the operation. Which errors should be saved inside the map without throwing RuntimeException and which ones should throw Java's RuntimeException and stop the execution of the experiment? In other words, how do we define a major error from a minor error?
Suggestions:
* All IllegalArgument
* All IOException thrown because of a problem reading or writing a file are minor errors
* All Exception from the execution of an operation are minor errors
Changed in ebsd-image: | |
assignee: | nobody → Philippe Pinard (philippe.pinard) |
assignee: | Philippe Pinard (philippe.pinard) → RML00 (rml-image) |
assignee: | RML00 (rml-image) → Philippe Pinard (philippe.pinard) |
Changed in ebsd-image: | |
status: | New → Opinion |
status: | Opinion → Confirmed |
Changed in ebsd-image: | |
status: | Fix Committed → Fix Released |
I agree to treat IllegalArgument Exceptions as major errors. It means there has been a programming or configuration error. This is bad.
I think IOExceptions should also be considered major errors. This means that data is lost which is bad too.
For minor errors, I would create a special exception called EBSDMinorException. This exception would hold the error number and the error message. It could be caught by the engine and the error number could then be placed in the error map.