Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support error "level" #270

Closed
adourish opened this issue Mar 11, 2017 · 10 comments
Closed

Support error "level" #270

adourish opened this issue Mar 11, 2017 · 10 comments

Comments

@adourish
Copy link

We often need to distinguish the types of errors that are generated. Some errors are not serious. Adding an error level would be very helpful.

"level" = ["critical","error", "warning","success";

e.g. Prevent large amounts of data from getting stored into a repository. This feature would add some complexity to the result object.

schema:
{
"type": "string",
"level": "critical",
"maxLength": 50000
}

@epoberezkin
Copy link
Member

I don't think it is in the scope of the specification. It is related to a wider issue of error reporting, which is not covered here.

@handrews
Copy link
Contributor

@adourish Are you talking about schema validation errors, errors in HTML forms, API request errors, or all of the above? For more discussion see #148 which is a similar request. I mostly agree with @epoberezkin but think that if we do a JSON UI Schema per #67 that this sort of thing could go there.

@adourish
Copy link
Author

  • It is related to error reporting.
  • It is not limited to UI.
    -- HTML forms
    -- Api calls
    -- Android app data validation
  • The "messages" property would help cover this use case
  • I still think that a "level" or "group" property is needed to differentiate the severity of an invalid item.
    JSON.Schema seems to be the perfect way to unit all the ways that you might need to validate data.

@dret
Copy link
Contributor

dret commented Mar 14, 2017

as one data point: for reporting API problems, https://tools.ietf.org/html/rfc7807 might be interesting to look at.

@handrews
Copy link
Contributor

See also #396

@awwright
Copy link
Member

awwright commented Jun 7, 2018

I think this suggestion is for a more general purpose ability to specify different courses of corrective action for different assertions. Here, type: "string" might be "critical", but another assertion maxLength: 5000 might be "error".

To this extent, this seems rather similar to e.g. providing localized error messages. I think we can close this out as a duplicate of that concern. I think #148 covers this. This is essentially a UI related proposal, though.

@handrews
Copy link
Contributor

handrews commented Jun 8, 2018

@awwright Yeah, I think that the non-UI parts of this are covered by some combination of #148 (specific error messages in the schema) and #396 (general standard output and error format).

We could consolidate the "level" concept into #148 as they are closely related.

@philsturgeon
Copy link
Collaborator

I'm not sure in what context I'd ever need see a difference between critical. error or a warning. Could you provide a use-case of when and how this would be used?

However it's planning on being used, it seems certain the initial example certainly would not fit. A property is not more or less important than any other, that's the job of required to make it optional or not, right?

Is it not possible for a specific implementation to infer the importance of specific types of error based on the context its running at? With #396 you could, for example, chose to ignore any errors that have the keyword failure reason as "format" if you don't care about format.

@gregsdennis
Copy link
Member

I think this is an application-level issue. The people who really care about this are the consumers, and they'll use an implementation that returns errors that can be easily identified by the application. Prioritization is an interpretation of the errors.

That said, perhaps the spec can indicate well-known error codes to be optionally included in the error reporting. This, then, leads us into the realm of #602 where each keyword carries with it certain meta-data which can be incorporated into the meta-schema (or some external document).

@Relequestual
Copy link
Member

Maybe this sort of behaviour could exist in a vocabulary which requires that sort of information.

For now, I feel it makes sense to close it. Maybe it could form part of an extended validation and reporting vocabulary, but I feel "validation" is not the right place for this.

#643 should be resolved before further discussion, if any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

8 participants