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

Inconsistent use of Ptrs for error types #79

Closed
jhorowitz opened this issue Sep 19, 2018 · 1 comment
Closed

Inconsistent use of Ptrs for error types #79

jhorowitz opened this issue Sep 19, 2018 · 1 comment
Assignees
Milestone

Comments

@jhorowitz
Copy link

What I did:
N/A

What I expected:
I expect to always receive an Error or and *Error but the Envelope type has a []*Error and the Part type has a []Error

What I got:
N/A

Release or branch I am using:
Master

(Please attach a sample message if you feel it will help reproduce the issue)

// Envelope is a simplified wrapper for MIME email messages.
type Envelope struct {
	...
	Errors      []*Error              // Errors encountered while parsing
	...
}
// Part represents a node in the MIME multipart tree.  The Content-Type, Disposition and File Name
// are parsed out of the header for easier access.
type Part struct {
	...
	Errors      []Error              // Errors encountered while parsing this part
	...
}

I'm happy to make a PR if you agree that this is something which should be addressed. Thanks for the great library, btw!

@jhillyerd
Copy link
Owner

Will have to do a bit of research and see if I had a good reason for doing it this way, I do not remember.

I did some work in develop to satisfy Go error interface #60 - but it looks like it still uses a mix of pointer and value types.

@jhillyerd jhillyerd added this to the v1.0.0 milestone Oct 20, 2018
@jhillyerd jhillyerd modified the milestones: v1.0.0, v0.3.0 Nov 1, 2018
@jhillyerd jhillyerd self-assigned this Nov 1, 2018
@jhillyerd jhillyerd added the bug label Nov 1, 2018
@jhillyerd jhillyerd added the done label Nov 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants