Format error messages, do not show exception text

[kMutagene]

Error output that ends up in the jsunit file is too verbose. It contains the full exception message with stacktrace. If the goal is to provide helpful insights on what is wrong in the arc, I suggest cleaning up the error messages.

Here is an example on how this gets displayed (rendered junit file on gitlab):

• Talking about an "entity" here is weird.

• There is way too much text

• Ideally, the error message should be short and simple, e.g.: Folder was not present: "./.git/hooks"

• As a future improvement: maybe replace the . signifying the arc root with the path supplied via ARC_PATH

• [ ] Format error messages

• [x] Do not show exception text

[omaus]

Already tracked and in progress. 👍

"entity" was chosen as the broadest term to cover all values since we want to keep the ontology as minimal as possible.

[kMutagene]

"entity" was chosen as the broadest term to cover all values since we want to keep the ontology as minimal as possible.

Still a weird choice imo. This is a user-facing message. It might be absolutely clear for you, but i see this as a potential friction point. Adding folder and file to that ontology seems like a minimum of work for much gain.

[omaus]

"entity" was chosen as the broadest term to cover all values since we want to keep the ontology as minimal as possible.

Still a weird choice imo. This is a user-facing message. It might be absolutely clear for you, but i see this as a potential friction point. Adding folder and file to that ontology seems like a minimum of work for much gain.

Thing is, it's not only "file" and "folder" to add, but also "value", "term", "unit", [...] , which can make the ontology bloated quite fast. But I see your point. If it confuses the user too much it does not help. Maybe we find a solution or at least a compromise to this in the (near) future.

[kMutagene]

Thing is, it's not only "file" and "folder" to add, but also "value", "term", "unit"

Then it might be even more important to be specific. How else can we expect the user to fix the issues with the arc if we do not point out what is wrong with it specifically?

[kMutagene]

I think this can be closed, as the message is quite okay now and we also want to change how messages are generated in v2. Thoughts @omaus?

[omaus]

Hm... I dunno. I would like to leave it open and close it when merging v2 tbh.

[kMutagene]

Then we should add the format specification we talked about to this issue and add it to 2.0.0