Signaling of fatal/blocking errors

[hdietze]

While experimenting with the reasoner command/operation. I noticed that the method just silently returns (and maybe event writes the result to a file) in case of an inconsistent ontology. There is no change in exit code (command-line level) or Java return value to indicate that there was an fatal problem.

In general we need an agreed up on mechanism to signal an error for a command (should we really use exceptions for this?). This should also result in a non-normal exit code for the command-line.

[jamesaoverton]

I agree that we need to fix the exit codes.

I think that Operations should throw exceptions, and not just exit. This is important for testing failures.

The Commands can probably just exit on problems. I've tried to make each Command work by itself (each one can be called directly from its main method) and work inside a CommandManager. If we want to maintain that system, then we have to decide on that interaction.

[cmungall]

I suggest an IncoherentOntologyException, for cases when the ontology has either unsatisfiable classes, or is inconsistent

[cmungall]

Did something change with logging? We don't seem to do info-level logging any more.

Now the unsats are completely unvisible unless you run with -vv

[cmungall]

Ah, nothing changed. It's just a difference between materialize and reason commands. The former uses log.error (which I think is appropriate) rather than info.

It also exits if unsat

[cmungall]

Additional quibble with the reporting in reason. It will say "There are N unsatisfiable classes in the ontology.", where N includes owl:Nothing

[jamesaoverton]

I changed the default level to ERROR to prevent all the noise from the other libraries: #107

What would be better?

[cmungall]

That's fine I think

I'm working on exceptions at the moment