[!info] 👍 Rule of thumb: Avoid try/catch as much as possible
try/catch is BAD. It hurts the application performance. Hence, all try/catch must to be justified.
You should put a comment to justify why would you have to try/catch here?
For example a BAD Code:
| /* Default value */ | |
| :root { | |
| color-scheme: light; | |
| --rz-alert-message-margin: 0.125rem 0; | |
| --rz-alert-icon-margin: 0.125rem 0; | |
| --rz-base: #eeeeee; | |
| --rz-base-50: #fafafa; | |
| --rz-base-100: #f5f5f5; | |
| --rz-base-200: #eeeeee; | |
| --rz-base-300: #e0e0e0; |
| <html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"></head><body><h1>Registered Services in a blank .NET 9 Web API application</h1><table border="1"><thead><tr><th>Counter</th><th>Abstraction Type</th><th>Lifetime</th><th>Concrete Implementation</th></tr></thead><tbody><tr><td>1</td><td>Microsoft.Extensions.Hosting.IHostingEnvironment</td><td>Singleton</td><td>Microsoft.Extensions.Hosting.Internal.HostingEnvironment</td></tr><tr><td>2</td><td>Microsoft.Extensions.Hosting.IHostEnvironment</td><td>Singleton</td><td>Microsoft.Extensions.Hosting.Internal.HostingEnvironment</td></tr><tr><td>3</td><td>Microsoft.Extensions.Hosting.HostBuilderContext</td><td>Singleton</td><td>Microsoft.Extensions.Hosting.HostBuilderContext</td></tr><tr><td>4</td><td>Microsoft.Extensions.Configuration.IConfiguration</td><td>Singleton</td><td>System.Func`2[[System.IServiceProvider, System.ComponentModel, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a],[Microsoft.Extensions.Configurat |
If you have to review a Pull Request (or Merge Request) in an unfamiliar C# codebase, what should you check? Here is my checklist for reviewing a C# codebase without fully knowing what it does:
Since we don’t know much about what the code is doing, the review should focus on best practices:
try/catch blocks.
| using System.Security.Cryptography; | |
| using System.Text; | |
| namespace Lemonway.TransactionService.Application | |
| { | |
| public static class AesEncryptionHelper | |
| { | |
| public static string Encrypt(string payload, string secret) | |
| { | |
| byte[] iv = new byte[16]; |
| // Place your key bindings in this file to override the defaultsauto[] | |
| [ | |
| { | |
| "key": "ctrl+t", | |
| "command": "workbench.action.togglePanel" | |
| }, | |
| { | |
| "key": "ctrl+shift+f4", | |
| "command": "workbench.action.closeOtherEditors" | |
| }, |
Your HTML page (the host page) has an Iframe. The Iframe source is on other domain, so you will have to use the window.postMessage() for cross-origin communication.
But this communication is only in 1 direction (The Iframe can inform the Host or the Host can inform the Iframe)
This article shows you how to make the Request/Reply communication using postMessage() and MessageChannel combination.
The article did not show you how to add a timeout to the communication, so the Iframe might wait forever if the Host did not response.
I will resume the technique by some codes snippets and at the same time add the missing timeout implementation.
API's designer often categorize errors into "Technical" and "Functional" (or "Business") errors. However, this distinction may not make sense:
We will explore the distinction between "real technical errors" and "fake technical errors". "Fake technical errors" are initially technical but later manifest as business errors, thus becoming "fake technical errors."
Read Part 1: MediatR vs MassTransit Mediator - Differences
The MassTransit Mediator implementation is more powerful than MediatR implementation, but also more complicate to use. Unit Testing a MassTransit Consumer is not a nice experience.
In this article I will propose some techniques to simplify the MassTransit Consumer and to make them look as straight forward as a MediatR handler.
We will study a very common use case (the most common use case which I can think of):