📊 Рейтинг постов

Вы всю неделю ставили нам лайки, а мы выбрали топ по реакциям:

• 100 RPS Rate Limiting
• Закон Брукса в разработке
• Антиспам в .NET
• FluentValidation в API
• StackTraceHiddenAttribute

Давайте выберем самый лучший пост в голосовании.

Что добавить в следующий спринт? Пишите! 👇

🐸Библиотека шарписта

#entry_point

⚙️ Один обработчик вместо сотни try catch

Когда в проекте десятки эндпоинтов, разъезжающий по коду try catch быстро превращается в свалку. Гораздо проще один раз настроить глобальный маппинг исключений в HTTP статус и возвращать нормальные ProblemDetails для всех ошибок.

ASP.NET уже умеет работать с ProblemDetails из коробки, нужно только включить службу и повесить обработчик ошибок.

В примере вся логика перевода исключений в HTTP ответы живет в одном месте:

builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler(appErr =>
{
    appErr.Run(async ctx =>
    {
        var ex = ctx.Features.Get<IExceptionHandlerFeature>()?.Error;

        var (status, title) = ex switch
        {
            ConcurrencyException => (StatusCodes.Status409Conflict, "Concurrency conflict"),
            NotFoundException    => (StatusCodes.Status404NotFound, "Resource not found"),
            _                    => (StatusCodes.Status500InternalServerError, "Server error")
        };

        ctx.Response.StatusCode = status;

        await ctx.Response.WriteAsJsonAsync(new ProblemDetails
        {
            Status   = status,
            Title    = title,
            Detail   = app.Environment.IsDevelopment() ? ex?.Message : null,
            Instance = ctx.Request.Path
        });
    });
});

Любые новые исключения добавляются через одну запись в switch, без походов по контроллерам, а все ответы об ошибках приходят в едином формате application/problem+json, что упрощает жизнь фронту и интеграциям.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#sharp_view

👨‍💻 Не хватает комментария «Создаёт переменную x равную 10»

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#garbage_collector

🚦 SemaphoreSlim в проде — не просто «асинхронный lock»

SemaphoreSlim часто кидают в код как самое простое решение и успокаиваются. В проде этого мало, ведь малейшая ошибка с Release, областью блокировки или per-key словарем легко превращается в дедлок, гонку или утечку памяти.

Самый частый фейл — банальное «забыли Release». Исключение между WaitAsync и finally и семафор навсегда занят поэтому все будущие вызовы повисают. Помогает только жесткое правило всегда оборачивать WaitAsync в try finally и не вставлять лишний код между ними особенно никакой логики которая может бросить исключение.

Вторая классика — блокировки внутри async кода. Варианты вроде _lock.Wait() или .Result внутри секции под SemaphoreSlim открывают прямую дорогу к дедлокам, потому что блокирующий вызов держит поток, а продолжение ждет этот же поток.

Общий принцип не блокировать внутри асинхронной критической секции если нужно синхронное API выносить его в Task.Run до входа в lock.

Поэтому в проде почти всегда лучше прятать SemaphoreSlim за абстракцией AsyncLock. Обертка с LockAsync() возвращающей IDisposable снимает часть рисков.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#il_люминатор