You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This release introduces the SendError type which satisfies the error interface and provides a better way to identify delivery errors. A new sendError field has been added to the Msg as well, to also allow per-message error handling in bulk mailings.
We've also added different SendErrReason that indicate the different things that can go wrong during mail delivery. These reasons can be checked for, for each Msg using the errors.Is methods. Alternatively, the errors.As method can be used to unwrap the SendError to get access to it's methods. The SendError provides a IsTemp method that returns true if the delivery error is of temporary nature.
This is useful for delivery retries. For example the following code could be used to decide whether the error is retryable or not:
iferr:=c.DialAndSend(m); err!=nil {
varse*mail.SendErroriferrors.As(err, &se) &&se.IsTemp() {
// retryable errorlog.Printf("temporary error, will re-try")
/* perform some re-try logic here */
}
// permanent errorlog.Fatal(err)
}
If the Send method runs into more than one error during delivery, these errors are accumulated and returned with the reason ErrAmbiguous, since it's not possible to exactly say what caused the error. For this it comes handy, that the *Msg now provides per-message send errors. The *Msg now has HasSendError(), SendErrorIsTemp() and SendError(). While HasSendError() simply returns a bool in case a *Msg failed during delivery and SendErrorIsTemp() returns true if it's a temporary error, the SendError() will return the full SendError error of the corresponding *Msg.
The Error() method of SendError will return a detailed error string based on the accumulated errors that were collected during the delivery.
Thanks to @imirkin and @iwittkau for providing valueable feedback and performing code review on the PR.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This release introduces the
SendError
type which satisfies the error interface and provides a better way to identify delivery errors. A newsendError
field has been added to theMsg
as well, to also allow per-message error handling in bulk mailings.We've also added different
SendErrReason
that indicate the different things that can go wrong during mail delivery. These reasons can be checked for, for eachMsg
using theerrors.Is
methods. Alternatively, theerrors.As
method can be used to unwrap theSendError
to get access to it's methods. TheSendError
provides aIsTemp
method that returns true if the delivery error is of temporary nature.This is useful for delivery retries. For example the following code could be used to decide whether the error is retryable or not:
If the
Send
method runs into more than one error during delivery, these errors are accumulated and returned with the reasonErrAmbiguous
, since it's not possible to exactly say what caused the error. For this it comes handy, that the*Msg
now provides per-message send errors. The*Msg
now hasHasSendError()
,SendErrorIsTemp()
andSendError()
. WhileHasSendError()
simply returns a bool in case a*Msg
failed during delivery andSendErrorIsTemp()
returns true if it's a temporary error, theSendError()
will return the fullSendError
error of the corresponding*Msg
.The
Error()
method ofSendError
will return a detailed error string based on the accumulated errors that were collected during the delivery.Thanks to @imirkin and @iwittkau for providing valueable feedback and performing code review on the PR.
What's Changed
Full Changelog: v0.3.6...v0.3.7
This discussion was created from the release v0.3.7: Improved delivery error handling.
Beta Was this translation helpful? Give feedback.
All reactions