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

Accumulate duplicated keys #169

Closed
MiSikora opened this issue Aug 12, 2021 · 6 comments
Closed

Accumulate duplicated keys #169

MiSikora opened this issue Aug 12, 2021 · 6 comments
Labels
enhancement New feature or request good first issue Good for newcomers stale

Comments

@MiSikora
Copy link

In case of multiple key duplicates I would like to see information about all of them and not first one encountered. Would it be possible to make it a configurable behaviour? I can make a PR if it is something you see fitting for the library.

@charleskorn
Copy link
Owner

Hi @MiSikora, if you're interested in making a PR, that would be a great enhancement. I'm not sure we need to make it configurable - I'm thinking we can just always report all duplicates. What do you think?

@charleskorn charleskorn added enhancement New feature or request good first issue Good for newcomers labels Aug 12, 2021
@MiSikora
Copy link
Author

MiSikora commented Aug 13, 2021

Sure, if you think it would be a good default I'm all for it.

@MiSikora
Copy link
Author

MiSikora commented Aug 13, 2021

I played around with it for a while today and I have couple of questions.

public open class YamlException(
override val message: String,
public val path: YamlPath,
override val cause: Throwable? = null
) : SerializationException(message, cause) {
public val location: Location = path.endLocation
public val line: Int = location.line
public val column: Int = location.column
override fun toString(): String = "${this::class.qualifiedName} at ${path.toHumanReadableString()} on line $line, column $column: $message"
}

Is toString() override on YamlException necessary? Exceptions have messages and overriding toString() seems a bit overzealous. Also, are path, line and column properties needed? With them present I find it hard to represent a cumulative error result and I don't want to change each property to a collection just for the sake of it.

I could create some other base exception and make YamlException and DuplicateKeysException inherit from it, but I don't know what you think of it (to me it seems a bit contrived compared to removing properties from the base exception). It would be more or less something like this.

// New exception
public open class YamlException(
  override val message: String,
  override val cause: Throwable? = null,
) : SerializationException(message, cause)

// Current YamlException
public open class SinglePathYamlException(
  override val message: String,
  public val path: YamlPath,
  override val cause: Throwable? = null,
) : YamlException(message, cause)

// New exception for multiple duplicate keys, probably remove DuplicateKeyException
public class DuplicateKeysException : YamlException

@charleskorn
Copy link
Owner

Great question.

I'd like to preserve the path and location (line and column) information wherever possible - this is really helpful when presenting information about the error to a user, and I know of at least one consumer of the library that uses this information extensively. For example, being able to say "property 'blah' on line 2, column 5 has value 'abc' which is not a valid boolean value" is useful information for a human.

I think this is the first case where we can't definitively provide one path and location as the source of the error (the previous DuplicateKeyException worked around this with the originalPath and duplicatePath properties which was not quite right), so I think the idea of having a base exception class with no paths or locations, and then a class for exceptions with a single path and another for duplicate keys is OK.

@stale
Copy link

stale bot commented Jul 7, 2022

This issue has been automatically marked as stale because it has not had any activity in the last 60 days. It will automatically be closed if no further activity occurs in the next seven days to enable maintainers to focus on the most important issues.
If this issue is still affecting you, please comment below within the next seven days.
Thank you for your contributions.

@stale stale bot added the stale label Jul 7, 2022
@stale
Copy link

stale bot commented Jul 14, 2022

This issue has been automatically closed because it has not had any recent activity.

@stale stale bot closed this as completed Jul 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants