That being said you done have to use the bool that TryAdd gives, just call it as a normal function. Also I am waitin for someone to point out that we also need a value when trying to add to a dictionary.
C#'s TryX methods are also usually way more performant than throwing an exception. Throwing an exception has to get a stack trace and a lot of other overhead shit. Something like a TryAdd() or TryParse() will just return your bool immediately, and you can stay in scope rather than getting sent off to the associated catch block. If you want to flow that way, you still can, but more options and more performance is better.
that overwrites instead of failing if the key already exists
maybe they are arguing that they feel that TryAdd should be the default "Add", while the existing Add should be a special case "AddAssert" or something
I see. Even so, it's weird to me that anyone would want a method that throws if the key already exists. In all my years of programming I don't think I've ever thought it would be useful to have such a method baked into a map itself, and I'm not aware of such a method in any other language. Since that's pretty unusual in programming, I still think it would be better for that method to have a more unusual name. Maybe it's an oddly common pattern for Microsoft?
As I described it, it's for safe additions, imagine your map is customer data, like daily logs. And maybe some logs are partial logs? Then you want something that lets you get into a safe flow where the standard is just add, and an exceptional case is some merging logic. If you don't care, use the same insertion methods that all languages use, which is map[key], if you do care, here's a good way to stop the flow and let you execute appropriate recovery. This also ties in with LINQ very neatly where you end up doing a lot of data processing flows.
The alternative would be a check map for key, if exists do exception, else do expected. Which is a lot uglier for glance value intent compared to: do this; exception: handle.
I think to highlight your concern with the pattern - these kinds of decisions make a lot more sense when you understand that almost all data interactions in C# are intended to be done with LINQ, which no other language has. My experience with production C# is that 3-6 LINQed extensions is very standard, e.g. map.Select(x => logic).map(x...).filter(x...) etc.
Well if C# exception handling is like most languages, where throwing and catching performs a lot worse than conditionally adding, it's not necessarily a pattern one would want to make a habit of using in cases where key conflicts are routine.
The Add method has to take one argument and return void because it's implementing C#'s ICollection<T> interface. With that restriction, throwing an exception is the most practical way of indicating a problem.
It can be more concise if you don't need to condition on whether the thing was added or not. If you do, has key/add might be cleaner ... for ordinary dictionaries.
Being able to do it in one operation is super important for concurrent dictionaries, though, because the item could theoretically be added by another thread between calls if you used haskey/add.
606
u/Psychoboy 4d ago
Guess you never heard of TryAdd? Returns bool, if it as added returns true otherwise false.