Introduce KError enum for more maintainable error handling

[gtrepta]

No description provided.

[tothtamas28]

Is this change preparing for a specific feature? At the moment, all error types still just wrap a String, but this makes the code more complex and increases coupling between the modules.

[tothtamas28]

Consider defining pub struct KoreLexerError in lexer.rs and pub struct KoreParserError in parser.rs. This reduces coupling between the two modules and keeps error definitions close to their source.

There doesn’t seem to be a strong need to handle these two errors uniformly. But even if such a need exists, you can still define a wrapper type:

pub enum KError {
    ParserError(KoreParserError),
    LexerError(KoreLexerError),
}

[tothtamas28]

As long as it serves its purpose, I think it's reasonable to keep the error as a String here. Clients of this type can still convert or wrap the error however they see fit.

[gtrepta]

Is this change preparing for a specific feature? At the moment, all error types still just wrap a String, but this makes the code more complex and increases coupling between the modules.

I guess at the moment I'm unsure what the best way to handle errors are. My idea was to make one generic error enum that can be extended with any new variants that are needed in the library, and extending From/Into impls simply adds a match arm.

Your concern about coupling makes sense, though. This would make a lot of modules depend on error.rs. Defining the error structs locally sounds more sensible, and inverses the dependencies if we make a wrapper around all of them (easy to remove it if we want to).

I am trying to create python bindings for the kore structures. The library I am using (pyo3) has a PyErr type which when returned raises an exception on the python side, so I thought it would be a good idea to have some way to control what type of exception is raised (parser/lexer errors can become ValueErrors, for instance). It's likely that I can just continue with Strings and map_err them to ValueErrors for now, so I will shelve this PR at least for today and think about it some more.