display validation errors in a more accesible manner

[MJochim]

In my opinion, errors during json validation contain very useful information that some users might be able to handle properly if they were presented in a different manner. Currently, this is what a validation error message looks like:

All the useful information is on the first line. The rest is basically the call stack and it is just overwhelming.

One very easy solution might be to delete the stack from the error object. In places like this:

EMU-webApp/app/scripts/services/dbObjLoadSaveService.js

Line 79 in 06e9669

modalService.open('views/error.html', 'Error validating annotation file: ' + JSON.stringify(validRes, null, 4)).then(function () {

(there are a number of such places, try grep -r "Error validating" EMU-webApp/app/), calling delete validRes.stack; should do.

A more advanced approach would be to generate an even easier-to-read version by only looking at validRes.dataPath and validRes.message (and maybe validRes.code - don't know what that code means).

[raphywink]

I don't know what you mean... I find that error message totaly legible :-). Kidding aside, I agree and we could try to do what you suggested but we would have to be carefull that validRes.stack is available for every error object we throw. Some of the server errors might be handled slightly differently (but I might be wrong). Would just mean we have to double check all the promise error handeling... not alot of fun but definately doable!

[MJochim]

I don't know what you mean... I find that error message totaly legible :-)

now that you say it - fällt es mir wie Schuppen von den Augen ("like scales from my eyes" - can you say that? ;))

It would of course make sense to make sure we are dealing with the same kind of error object every time. On the other hand, we can't really break anything, as delete validRes.stack won't do anything when stack does not exist on the object (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete). The only time delete throws is "in strict mode if the property is an own non-configurable property." I don't think this is the case for the stack property (might however double-check that).