Fix error logging for data/schema mismatch

[dobrynin]

Summary:

The error handling for invalid data seems to have broken after making some callbacks asynchronous. I believe this fixes it.

I had to do something a bit strange: console.logging the error information prior to actually throwing a ParseError. When I tried just throwing a ParseError, for some reason I only got one log in the console. The info came from a top-level attribute, even though the actual offending attribute was nested within that top-level attribute. Separating the log into a separate message made it so both the top-level (parent) attribute and the actually incorrect (nested) attribute logged their info.

GitHub linked issue:

#170, #331

Type (select 1):

• Bug fix
• Feature implementation
• Documentation improvement
• Testing improvement
• Test added to report bug (GitHub issue #--- @---)
• Something not listed here

Is this a breaking change? (select 1):

• 🚨 YES 🚨
• No
• I'm not sure

Is this ready to be merged into Dynamoose? (select 1):

• Yes
• No

Are all the tests currently passing on this PR? (select 1):

• Yes
• No

Other:

• I have searched through the GitHub pull requests to ensure this PR has not already been submitted
• I have updated the Dynamoose documentation (if required) given the changes I made
• I have added/updated the Dynamoose test cases (if required) given the changes I made
• I have run npm test from the root of the project directory to ensure all tests continue to pass
• I agree that all changes made in this pull request may be distributed and are made available in accordance with the Dynamoose license
• All of my commits and commit messages are detailed, explain what changes were made, and are easy to follow and understand
• I have confirmed that all my code changes are indented properly using 2 spaces
• I have filled out all fields above

[coveralls]

Pull Request Test Coverage Report for Build 813

• 14 of 17 (82.35%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 85.551%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/Attribute.js	14	17	82.35%

Totals
Change from base Build 810:	0.04%
Covered Lines:	2186
Relevant Lines:	2480

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 827

• 14 of 17 (82.35%) changed or added relevant lines in 1 file are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.1%) to 85.627%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/Attribute.js	14	17	82.35%

Files with Coverage Reduction	New Missed Lines	%
lib/Table.js	1	79.6%

Totals
Change from base Build 810:	0.1%
Covered Lines:	2187
Relevant Lines:	2480

---

💛 - Coveralls

[dobrynin]

I realized why just throwing an error wasn't giving all of the information. I've pushed a new commit which consolidates the messages from any errors that occur while recursively parsing an attribute.

[fishcharlie]

Do we need to add tests for this?

[dobrynin]

@fishcharlie, I've added a test and pushed new commits. Github doesn't seem to be updating the PR for some reason (there site was having issues this morning, may be related). I'm unaware of any way to do this manually. I'll check in on this later; hopefully the automatic update will have kicked in.

[fishcharlie]

@dobrynin Yeah doesn't look like it updated. Maybe try creating a new commit and push that? Like add a new line, commit that, remove it, commit, and push?

[dobrynin]

Cool, seems to have worked now. FYI I used the --allow-empty flag on git commit to push an empty commit. Even better would have been to just update the hash on the last commit and force push somehow, but I didn't really feel like messing with that.

[fishcharlie]

LGTM