[GSoC,v4,0/2] smtp_auth_maybe: unified error capture and status code processing optimization

Message

Zheng Yuting March 16, 2025, 5:09 a.m. UTC

This v4 patch series includes two improvements:

1. Unified error capture:
Consolidate exception handling within a single eval block by introducing
local variables to store results and error states, thereby streamlining
code structure and enabling future extensibility.

2. Status code processing optimization:
After catching the authentication exception, parse the three-digit status
code in the error message, For temporary errors (4yz), only print warnings
and return success, while for permanent errors (5xx), return failure,
Unrecognized status codes are treated as permanent errors by default.

Zheng Yuting (2):
  Unify capture of SMTP errors
  Error handling for SMTP status codes

 git-send-email.perl | 62 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 45 insertions(+), 17 deletions(-)

--
2.48.1

Comments

Junio C Hamano March 17, 2025, 11:01 p.m. UTC | #1

Zheng Yuting <[e-mail]> writes:

> This v4 patch series includes two improvements:
>
> 1. Unified error capture:
> Consolidate exception handling within a single eval block by introducing
> local variables to store results and error states, thereby streamlining
> code structure and enabling future extensibility.
>
> 2. Status code processing optimization:
> After catching the authentication exception, parse the three-digit status
> code in the error message, For temporary errors (4yz), only print warnings
> and return success, while for permanent errors (5xx), return failure,
> Unrecognized status codes are treated as permanent errors by default.
>
> Zheng Yuting (2):
>   Unify capture of SMTP errors
>   Error handling for SMTP status codes

Give title your commits following the project convention
(Documentation/SubmittingPatches:summary-section).

I think these two can share "sendemail:" as their "<area>:" part.

	sendemail: capture errors in an eval {} block
	sendemail: finer-grained SMTP error handling

or something like that, perhaps.

For both patches, the usual way to compose a log message of this
project is to

 - Give an observation on how the current system work in the present
   tense (so no need to say "Currently X is Y", just "X is Y"), and
   discuss what you perceive as a problem in it.

 - Propose a solution (optional---often, problem description
   trivially leads to an obvious solution in reader's minds).

 - Give commands to the codebase to "become like so".

in this order.  I got an impression that at least your 1/2 it was
unclear which part was explaining the state before the patch and
which part was about the state after the patch.

Thanks.