From: Junio C Hamano <gitster@pobox.com>
To: Zheng Yuting <05zyt30@gmail.com>
Cc: git@vger.kernel.org, meetsoni3017@gmail.com
Subject: Re: [GSoC PATCH v8 2/2] send-email: finer-grained SMTP error handling
Date: Tue, 25 Mar 2025 08:34:25 -0700 [thread overview]
Message-ID: <xmqqmsd9m8e6.fsf@gitster.g> (raw)
In-Reply-To: <20250324145332.571813-3-05ZYT30@gmail.com> (Zheng Yuting's message of "Mon, 24 Mar 2025 22:53:32 +0800")
Zheng Yuting <05zyt30@gmail.com> writes:
> - # NOTE: SMTP status code handling will be added in a subsequent commit,
> - # return 1 when failed due to non-credential reasons
> - return $error ? 1 : ($result ? 1 : 0);
> + return handle_smtp_error($error, $result);
It was a bit surprising that the new handle-smtp-error sub handles
the case without an error. I would actually have expected for it to
be something like:
return ($error
? handle_smtp_error($error)
: ($result ? 1 : 0));
I.e., we used to unconditionally return 1 upon error, and the only
change introduced by this step is to classify $error with the helper
function better and behave differently depending on the error.
Having said that ...
> +sub handle_smtp_error {
> + my ($error, $result) = @_;
> +
> + # If no error is present, return the result directly
> + return $result ? 1 : 0 unless $error;
... as the "no error" case is implemented as an early return, the
mental burden on the readers is not so bad. They can concentrate on
the error case when reading the remainder of the function.
Still, it would be with even less mental burden if the no-error case
is handled by the caller to make this function only about error cases.
> + # Check if an error was captured
> + # Parse SMTP status code from error message in:
> + # https://www.rfc-editor.org/rfc/rfc5321.html
> + if ($error =~ /\b(\d{3})\b/) {
> + my $status_code = $1;
> + if ($status_code =~ /^4/) {
> + # 4yz: Transient Negative Completion reply
> + warn "SMTP transient error (status code $status_code): $error";
> + return 1;
> + } elsif ($status_code =~ /^5/) {
> + # 5yz: Permanent Negative Completion reply
> + warn "SMTP permanent error (status code $status_code): $error";
> + return 0;
> + }
> + # If no recognized status code is found, treat as transient error
> + warn "SMTP unknown error: $error. Treating as transient failure.";
> + return 1;
> + }
> +
> + # If no status code is found, treat as transient error
> + warn "SMTP generic error: $error";
> + return 1;
> +}
> +
> sub ssl_verify_params {
> eval {
> require IO::Socket::SSL;
next prev parent reply other threads:[~2025-03-25 15:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 6:46 [GSoC PATCH v3 0/1] Refactor SMTP Auth Error Handling Zheng Yuting
2025-03-12 6:46 ` [GSoC PATCH v3 1/1] Unify SMTP auth error handling Zheng Yuting
2025-03-13 19:58 ` Junio C Hamano
2025-03-14 12:55 ` Yuting Zheng
2025-03-16 5:09 ` [GSoC PATCH v4 0/2] smtp_auth_maybe: unified error capture and status code processing optimization Zheng Yuting
2025-03-16 5:09 ` [GSoC PATCH v4 1/2] Unify capture of SMTP errors Zheng Yuting
2025-03-16 5:09 ` [GSoC PATCH v4 2/2] Error handling for SMTP status codes Zheng Yuting
2025-03-17 23:01 ` [GSoC PATCH v4 0/2] smtp_auth_maybe: unified error capture and status code processing optimization Junio C Hamano
2025-03-19 2:02 ` [GSoC PATCH v5 0/2] sendemail: improve error capture and status code handling Zheng Yuting
2025-03-19 2:02 ` [GSoC PATCH v5 1/2] sendemail: capture errors in an eval {} block Zheng Yuting
2025-03-19 2:02 ` [GSoC PATCH v5 2/2] sendemail: finer-grained SMTP error handling Zheng Yuting
2025-03-19 6:35 ` [GSoC PATCH v5 0/2] sendemail: improve error capture and status code handling Meet Soni
2025-03-21 2:51 ` [GSoC PATCH v6 0/2] send-email: " Zheng Yuting
2025-03-21 2:51 ` [GSoC PATCH v6 1/2] send-email: capture errors in an eval {} block Zheng Yuting
2025-03-21 2:51 ` [GSoC PATCH v6 2/2] send-email: finer-grained SMTP error handling Zheng Yuting
2025-03-21 15:38 ` [GSoC PATCH v6 0/2] send-email: improve error capture and status code handling Junio C Hamano
2025-03-23 2:21 ` [GSoC PATCH v7 " Zheng Yuting
2025-03-23 2:21 ` [GSoC PATCH v7 1/2] send-email: capture errors in an eval {} block Zheng Yuting
2025-03-23 2:21 ` [GSoC PATCH v7 2/2] send-email: finer-grained SMTP error handling Zheng Yuting
2025-03-24 6:00 ` Junio C Hamano
2025-03-24 14:53 ` [GSoC PATCH v8 0/2] send-email: improve error capture and status code handling Zheng Yuting
2025-03-24 14:53 ` [GSoC PATCH v8 1/2] send-email: capture errors in an eval {} block Zheng Yuting
2025-03-24 14:53 ` [GSoC PATCH v8 2/2] send-email: finer-grained SMTP error handling Zheng Yuting
2025-03-25 15:34 ` Junio C Hamano [this message]
2025-03-26 7:52 ` [GSoC PATCH v9 0/2] send-email: improve error capture and status code handling Zheng Yuting
2025-03-26 7:52 ` [GSoC PATCH v9 1/2] send-email: capture errors in an eval {} block Zheng Yuting
2025-03-26 7:52 ` [GSoC PATCH v9 2/2] send-email: finer-grained SMTP error handling Zheng Yuting
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmsd9m8e6.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=05zyt30@gmail.com \
--cc=git@vger.kernel.org \
--cc=meetsoni3017@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).