Skip to content

feat: add error report when default value is invalid - #59

Merged
creasty merged 3 commits into
creasty:masterfrom
marxoffice:master
Sep 12, 2026
Merged

feat: add error report when default value is invalid#59
creasty merged 3 commits into
creasty:masterfrom
marxoffice:master

Conversation

@marxoffice

Copy link
Copy Markdown
Contributor

Improved Error Reporting Mechanism - Pull Request

Overview

This patch includes two major improvements aimed at enhancing the error reporting friendliness.

Commit Contents

Commit 1: Improved Error Reporting for Invalid Default Values (5058a89)

Key Improvements:

  • Added detailed error wrapping mechanism in the setField function
  • Error messages now include field name, default value, and original error details
  • Modified error handling logic for all basic data types

Error Report Example:

type ErrIntDefault struct {
	ErrInt int `default:"abc"`
}

will report error

error on set Field:[ErrInt], DefaultValue:[abc] Error:[strconv.ParseInt: parsing "abc": invalid syntax]

Commit 2: Improved Subfield Error Reporting (df4441b)

Key Improvements:

  • Fixed the issue of error propagation in nested structures
  • Ensured that errors in pointer type fields are correctly propagated upward

Test Case Example:

type SubErrorDefault struct {
    ErrSlice  []string \`default:"[1,2,3]"\`  // Error here, correct default value is ["1", "2", "3"]
    NormalInt int      \`default:"1"\`
}

type ParentErrorDefault struct {
    NormalInt  int              \`default:"1"\`
    ErrChild   *SubErrorDefault \`default:"{}"\`
    NormalBool bool             \`default:"true"\`
}

// Before This Commit
Set(&SubErrorDefault{}) // will report error because parse json failed
Set(&ParentErrorDefault{}) // will not report error

// After This Commit
Set(&SubErrorDefault{}) // will report error because parse json failed
Set(&ParentErrorDefault{}) // will report error because set ErrChild failed

Usage Example

When using invalid default values in configuration structures, clear error information is now provided:

type Config struct {
    Port     int    \`default:"abc"\`  // Invalid integer value
    Timeout  string \`default:"30s"\` // Valid string value
}

cfg := &Config{}
if err := defaults.Set(cfg); err != nil {
    // Error message: error on set Field:[Port], DefaultValue:[abc] Error:[strconv.ParseInt: parsing "abc": invalid syntax]
    fmt.Println(err)
}

Summary

These improvements make the defaults library provide more friendly and detailed error information when encountering configuration errors.

@codecov

codecov Bot commented Nov 20, 2025

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 95.52239% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.68%. Comparing base (abebf4b) to head (6c20eed).
⚠️ Report is 2 commits behind head on master.

Files with missing lines Patch % Lines
defaults.go 95.52% 0 Missing and 3 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #59      +/-   ##
==========================================
+ Coverage   95.97%   96.68%   +0.71%     
==========================================
  Files           2        2              
  Lines         149      181      +32     
==========================================
+ Hits          143      175      +32     
  Misses          3        3              
  Partials        3        3              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

creasty pushed a commit that referenced this pull request Sep 12, 2026
#74 and #59 both changed setField's signature, so all five call sites plus the
signature conflicted. Resolved by grouping the per-field context rather than
threading it: a fieldTag carries the field's name, the tag's value and whether
the tag was present, which keeps setField to one context parameter instead of
three positional ones, two of them strings. That follows the review note on #74
about hoisting the tag out of shouldInitializeField.

The pointer recursion resolved in #59's favour, since propagating that error is
what closes #68.

There was also a semantic conflict the markers could not show. #74 made
`default:""` mean "this type's zero value", and #59 makes an unparsable value an
error -- so an empty tag on a numeric field started failing, because "" does not
parse. Master's own TestSet_EmptyTag and TestSet_PointerWithEmptyTag caught it.
parseErr now returns nil for an empty tag: there is nothing to parse, so there is
nothing to report, and the field keeps the zero value it already holds. One place
rather than seventeen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JjAoN3BBvc6dfT9pog3kMB
@creasty
creasty merged commit 0f626a7 into creasty:master Sep 12, 2026
2 of 3 checks passed
creasty added a commit that referenced this pull request Sep 12, 2026
Adopt #59: report an error for an invalid default value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants