`__str__` of verification errors

[mristin]

This issue has been forked from #10.

@alexgordtop wrote:

How do you think about enhancing the Error and Path classes from verification to something like this? I want to be able to print it - another option would be to make it json serializable...

Especially for cloud / server deployment it would be great to also have an "id_short_path" and an "identifier" where applicable - so that we're not forced to debug the structure. And for regex violations, the malformed value would be nice :)

class Path:
    """Represent the relative path to the erroneous value."""

    def __init__(self) -> None:
        """Initialize as an empty path."""
        self._segments = []  # type: List[Segment]

    @property
    def segments(self) -> Sequence[Segment]:
        """Get the segments of the path."""
        return self._segments

    def _prepend(self, segment: Segment) -> None:
        """Insert the :paramref:`segment` in front of other segments."""
        self._segments.insert(0, segment)

    def __str__(self) -> str:
        return "".join(str(segment) for segment in self._segments)

    def __repr__(self) -> str:
        return self.__str__()

class Error:
    """Represent a verification error in the data."""

    #: Human-readable description of the error
    cause: Final[str]

    #: Path to the erroneous value
    path: Final[Path]

    def __init__(self, cause: str) -> None:
        """Initialize as an error with an empty path."""
        self.cause = cause
        self.path = Path()

    def __str__(self) -> str:
        return f"\nCause: '{self.cause}', Path: '{self.path}'"

    def __repr__(self) -> str:
        return self.__str__()

[mristin]

@alexgordtop I deliberately did not implement that as the string representation is very application-specific. For example, I usually use "\n".join(f"* {error.path}: {error.cause}" for error in errors) when reporting errors in a CLI tool.

Other users might have different formatting requirements (e.g., you suggested Cause: ... Path: ...). I can't think of a good solution here, so tend to endorse no solution to a specific one.

__repr__ is yet another can of worms: should the segments be given with the classes instead of __str__ etc.

Is there a case in your application where you explicitly need __str__ or is it just convenience?

[alexgordtop]

The first str was already inside Path - so I thought, it would be handy to add repr. I'm a big fan of having a string representation of objects, that I can see in the variable of my ide while debugging - so that I'm not forced to "open" the objects to look inside. It's absolutely correct, that we will never meet all requirements with str / repr - but having something, that simplifies debugging, is just handy.

Usually I use something like "<Classname(key=value,key=value>" for a few significant attributes - just to help me to identify, in which object I should deep-dive.

[mristin]

@alexgordtop since it's only for debugging, I suggest to define only __repr__.

See: https://stackoverflow.com/questions/1436703/what-is-the-difference-between-str-and-repr

Please confirm (e.g., a thumb up to this message), and then I'll make a pull request.

[alexgordtop]

@mristin I'm totally fine with repr :)

Again, Path already had str - I just completed it for Error: https://github.com/aas-core-works/aas-core3.0-python/blob/4c35b97d78ff56e9189f9619c7a0269c0caf90e4/aas_core3/verification.py#L107

Additionally - what about adding more details to the error message - like the current / invalid value and the identifier / id_short_path? So that it's not even necessary to debug the thing in 90% of the cases?

[mristin]

@alexgordtop

Additionally - what about adding more details to the error message - like the current / invalid value and the identifier / id_short_path? So that it's not even necessary to debug the thing in 90% of the cases?

That is not really possible, i.e. it's quite difficult to formalize & transpile. Oftentimes it's not a single string property, but a relationship between properties etc. It would need quite some changes in aas-core-codegen.