We Keep Coding

How can I create a non-nullable variable when it's initialized in an event?

This is razor code but I think the same can happen in most any C# code in an event driven architecture.
private List<User> Users { get; set; }
protected override async Task OnInitializedAsync()
{
Users = await Context.Users.Include(u => u.Address).ToListAsync();
}
So the above code will initialize Users before it is ever accessed. However, it puts up a warning that a non-nullable variable is not being initialized.
Is this a case of assigning "default!" to it which is my way of saying don't worry it'll be initialized before it is accessed?
Update: This occurs inside a .razor page in the #code part. So it exists while the html is being rendered to pass back to the user's browser. I'm writing this code in an ASP.NET Core Blazor app.
The problem here is the Users object needs to be accessible to all the code in the .razor file. But the code is loaded in the async method. And this method is called as part of the .razor file creation, so it needs to be in there.

To elaborate on my comments, with too much pontification:
In OOP, regardless of language (be it Java, C#, C++, Swift, etc), the purpose of a class's constructor is to initialize the object-instance's state from any parameters, and also to establish class invariants.
(Btw, don't equate or confuse invariant with immutability: immutability is just a particular kind of invariant, it's perfectly acceptable for a class' objects to be mutable)
The principle of class-invariants is more-often-than-lot (in my opinion) lost on so-many (perhaps even most?) users of C#, specifically, because of how the C# language (and its associated documentation and libraries) has evolved towards preferring default (parameterless) constructors, post-construction initialization, and mutable properties - all of which cannot be reconciled with the CS-theoretical, not practical, limits of static analysis which the C# compiler uses for #nullable warnings.
The simple fact is only a class's constructor can make guarantees about the state of any of its instance fields (including auto-properties) - whereas (excepting required members in C# 11), a C# object-initializer is evaluated post-construction, is entirely optional, sets entirely arbitrary and non-exhaustive members.
Therefore, to make use of #nullable to the full-extent, one must simply get used to getting into the habit of writing parameterized constructors, despite their "expressive redundancy" in most cases (e.g. in a POCO DTO) having to repeat the class's members as ctor parameters and then assign each property in the ctor.
Though at least record types in C# 9 simplify this - but record types aren't as immutable as they seem: properties can still be overwritten with invalid values after the ctor has run in an object-initializer, which breaks the concept of class-invariants being enforced by the constructor - I'm really not happy with how that turned out in C# 9, grrr.
I appreciate that this isn't possible in many cases, such as with Entity Framework and EF Core, which (as of early 2023) still doesn't support binding database query results to constructor parameters, only to property-setters - but people often are unaware that many other libraries/frameworks do support ctor binding, such as Newtonsoft.Json supports deserializing JSON objects to immutable C# objects via [JsonConstructor] and attaching [JsonProperty] to each ctor parameter, for example.
In other cases, namely UI/UX code, where your visual component/control/widget must inherit from some framework-provided base-class (e.g. WinForms' System.Windows.Forms.Control, or WPF's Visual or Control, or in Blazor: Microsoft.AspNetCore.Components.ComponentBase) - you'll find yourself with seemingly contradictory precepts: you can only "initialize" the Control's state /data in the OnLoad/OnInitializedAsync method (not the constructor), but the C# compiler's #nullable analysis recognizes that only the constructor can initialize class members and properly establish that certain fields will never be null at any point. It's a conundrum and the documentation and official examples and tutorials do often gloss this over (sometimes even with = null!, which I feel is just wrong).
Taking Blazor's ComponentBase for example (as this is what the OP's code is targeting, after-all): immediately after when the ComponentBase subclass is created (i.e. the ctor runs), the SetParametersAsync method is called, only after that then is OnInitializedAsync called - and OnInitializedAsync can fail or need to be awaited, which means that the "laws" about constructors definitely still apply: any code consuming a ComponentBase type cannot necessarily depend any late initialization by OnInitializedAsync to be guaranteed, especially not any error-handling code.
For example, if the ctor left the List<User> Users { get; } property uninitialized (and therefore null, despite the type not being List<User>?) and OnInitializedAsync (which would set it to a non-null value) were to fail, and then if that ComponentBase subclass object were to be passed to some custom-error handling logic, then that error-handler itself would fail if it (rightfully, but incorrectly) assumed that the Users property would never be null.
However this convoluted arrangement could have been avoided if Microsoft designed Blazor to support some kind of Component-factory system whereby the OnInitialized{Async} logic could be moved into a factory-method or ctor with that all-or-nothing guarantee that we need for software we can reason about. But anyway...
So given the above, there exist a few solutions:
If this were a system entirely under your control (which Blazor is not, so this advice doesn't apply to you) then I would recommend you redesign the system to use factory-methods instead of post-ctor object initialization.
But as this is Blazor, it shares certain similarities in its databinding approach with WPF, "XAML", WinForms and others: namely its roots in having long-lived mutable view-models implementing INotifyPropertyChanged.
And this is the most important factor: because the view-model concept means that you shouldn't have List<T> as the collection-type for a property that will be used for data-binding: you're meant to use ObservableCollection<T>, which solves the problem: ObservableCollection<T> is meant to be initialized only once by the constructor (thus satisfying the never-null problem), and is designed to be long-lived and mutable, so it's perfectly-fine to populate it in OnInitializedAsync and OnParametersSet{Async}, which is how Blazor operates.
Therefore, in my opinion, you should change your code to this:
class UsersListComponent : ComponentBase
{
private Boolean isBusy;
public Boolean IsBusy
{
get { return this.isBusy; }
private set { if( this.isBusy != value ) { this.isBusy = value; this.RaiseOnNotifyPropertyChanged( nameof(this.IsBusy); } // INPC boilerplate, ugh: e.g. https://stackoverflow.com/questions/65813816/c-sharp-blazor-server-display-live-data-using-inotifypropertychanged
}
public ObservableCollection<User> Users { get; } = new ObservableCollection<User>();
protected override async Task OnInitializedAsync()
{
await this.ReloadUsersAsync(); // Also call `ReloadUsersAsync` in `OnParametersSetAsync` as-appropriate based on your application.
}
private async Task ReloadUsersAsync()
{
this.IsBusy = true;
this.Users.Clear(); // <-- The ObservableCollection will raise its own collection-modified events for you, which will be handled by the UI components data-bound to the exposed Users collection.
try
{
List<User> users = await this.Context.Users
.Include(u => u.Address)
.ToListAsync();
// ObservableCollection<T> doesn't support AddRange for historical reasons that we're now stuck with, ugh: https://github.com/dotnet/runtime/issues/18087#issuecomment-359197102
foreach( User u in users ) this.Users.Add( u );
}
finally
{
this.IsBusy = false;
}
}
}
Notice how, if the data-loading in OnInitializeAsync, via ReloadUsersAsync, fails due to an exception being thrown from Entity Framework (which is common, e.g. SQL Server timeout, database down, etc) then the class-invariants of UsersListComponent (i.e. that the Users collection is never null and the property always exposes a single long-lived object-reference) always remain true, which means any code can safely consume your UsersListComponent without risk of a dreaded unexpected NullReferenceException.
(And the IsBusy part is just because it's an inevitable thing to add to any ViewModel/XAML-databound class that performs some IO).

Object instance valid only for the current method

Is it possible to create an object that can register whether the current thread leaves the method where it was created, or to check whether this has happened when a method on the instance gets called?
ScopeValid obj;
void Method1()
{
obj = new ScopeValid();
obj.Something();
}
void Method2()
{
Method1();
obj.Something(); //Exception
}
Can this technique be accomplished? I would like to develop a mechanism similar to TypedReference and ArgIterator, which can't "escape" the current method. These types are handled specially by the compiler, so I can't mimic this behavior exactly, but I hope it is possible to create at least a similar rule with the same results - disallow accessing the object if it has escaped the method where it was created.
Note that I can't use StackFrame and compare methods, because the object might escape and return to the same method.

Changing method behavior based upon the source of the call is a bad design choice.
Some example problems to consider with such a method include:
Testability - how would you test such a method?
Refactoring the calling code - What if the user of your code just does an end run around your error message that says you can't do that in a different method than it was created? "Okay, fine! I'll just do my bad thing in the same method, says the programmer."
If the user of your code breaks it, and it's their fault, let it break. Better to just document your code with something like:
IInvalidatable - Types which implement this member should be invalidated with Invalidate() when you are done working with this.
Ignoring the obvious point that this almost seems like is re-inventing IDisposible and using { } blocks (which have language support), if the user of your code doesn't use it right, it's not really your concern.
This is likely technically possible with AOP (I'm thinking PostSharp here), but it still depends on the user using your code correctly - they would have to have it in the build process, and failing to function if they aren't using a tool just because you're trying to make it easy on them is evil.
Another point - If you are just attempting to create an object which cannot be used outside of one method, and any attempted operation outside of the method would fail, just declare it a local inside the method.
Related: How to find out which assembly handled the request

Years laters, it seems this feature was finally added to C# 7.2: ref struct.
Another related language feature is the ability to declare a value type that must be stack allocated. In other words, these types can never be created on the heap as a member of another class. The primary motivation for this feature was Span and related structures. Span may contain a managed pointer as one of its members, the other being the length of the span. It's actually implemented a bit differently because C# doesn't support pointers to managed memory outside of an unsafe context. Any write that changes the pointer and the length is not atomic. That means a Span would be subject to out of range errors or other type safety violations were it not constrained to a single stack frame. In addition, putting a managed pointer on the GC heap typically crashes at JIT time.
This prevents the code from moving the value to the heap, which partly solves my original problem. I am not sure how returning a ref struct is constrained, though.

How to enforce the use of a method's return value in C#?

I have a piece of software written with fluent syntax. The method chain has a definitive "ending", before which nothing useful is actually done in the code (think NBuilder, or Linq-to-SQL's query generation not actually hitting the database until we iterate over our objects with, say, ToList()).
The problem I am having is there is confusion among other developers about proper usage of the code. They are neglecting to call the "ending" method (thus never actually "doing anything")!
I am interested in enforcing the usage of the return value of some of my methods so that we can never "end the chain" without calling that "Finalize()" or "Save()" method that actually does the work.
Consider the following code:
//The "factory" class the user will be dealing with
public class FluentClass
{
//The entry point for this software
public IntermediateClass<T> Init<T>()
{
return new IntermediateClass<T>();
}
}
//The class that actually does the work
public class IntermediateClass<T>
{
private List<T> _values;
//The user cannot call this constructor
internal IntermediateClass<T>()
{
_values = new List<T>();
}
//Once generated, they can call "setup" methods such as this
public IntermediateClass<T> With(T value)
{
var instance = new IntermediateClass<T>() { _values = _values };
instance._values.Add(value);
return instance;
}
//Picture "lazy loading" - you have to call this method to
//actually do anything worthwhile
public void Save()
{
var itemCount = _values.Count();
. . . //save to database, write a log, do some real work
}
}
As you can see, proper usage of this code would be something like:
new FluentClass().Init<int>().With(-1).With(300).With(42).Save();
The problem is that people are using it this way (thinking it achieves the same as the above):
new FluentClass().Init<int>().With(-1).With(300).With(42);
So pervasive is this problem that, with entirely good intentions, another developer once actually changed the name of the "Init" method to indicate that THAT method was doing the "real work" of the software.
Logic errors like these are very difficult to spot, and, of course, it compiles, because it is perfectly acceptable to call a method with a return value and just "pretend" it returns void. Visual Studio doesn't care if you do this; your software will still compile and run (although in some cases I believe it throws a warning). This is a great feature to have, of course. Imagine a simple "InsertToDatabase" method that returns the ID of the new row as an integer - it is easy to see that there are some cases where we need that ID, and some cases where we could do without it.
In the case of this piece of software, there is definitively never any reason to eschew that "Save" function at the end of the method chain. It is a very specialized utility, and the only gain comes from the final step.
I want somebody's software to fail at the compiler level if they call "With()" and not "Save()".
It seems like an impossible task by traditional means - but that's why I come to you guys. Is there an Attribute I can use to prevent a method from being "cast to void" or some such?
Note: The alternate way of achieving this goal that has already been suggested to me is writing a suite of unit tests to enforce this rule, and using something like http://www.testdriven.net to bind them to the compiler. This is an acceptable solution, but I am hoping for something more elegant.

I don't know of a way to enforce this at a compiler level. It's often requested for objects which implement IDisposable as well, but isn't really enforceable.
One potential option which can help, however, is to set up your class, in DEBUG only, to have a finalizer that logs/throws/etc. if Save() was never called. This can help you discover these runtime problems while debugging instead of relying on searching the code, etc.
However, make sure that, in release mode, this is not used, as it will incur a performance overhead since the addition of an unnecessary finalizer is very bad on GC performance.

You could require specific methods to use a callback like so:
new FluentClass().Init<int>(x =>
{
x.Save(y =>
{
y.With(-1),
y.With(300)
});
});
The with method returns some specific object, and the only way to get that object is by calling x.Save(), which itself has a callback that lets you set up your indeterminate number of with statements. So the init takes something like this:
public T Init<T>(Func<MyInitInputType, MySaveResultType> initSetup)

I can think of three a few solutions, not ideal.
AIUI what you want is a function which is called when the temporary variable goes out of scope (as in, when it becomes available for garbage collection, but will probably not be garbage collected for some time yet). (See: The difference between a destructor and a finalizer?) This hypothetical function would say "if you've constructed a query in this object but not called save, produce an error". C++/CLI calls this RAII, and in C++/CLI there is a concept of a "destructor" when the object isn't used any more, and a "finaliser" which is called when it's finally garbage collected. Very confusingly, C# has only a so-called destructor, but this is only called by the garbage collector (it would be valid for the framework to call it earlier, as if it were partially cleaning the object immediately, but AFAIK it doesn't do anything like that). So what you would like is a C++/CLI destructor. Unfortunately, AIUI this maps onto the concept of IDisposable, which exposes a dispose() method which can be called when a C++/CLI destructor would be called, or when the C# destructor is called -- but AIUI you still have to call "dispose" manually, which defeats the point?
Refactor the interface slightly to convey the concept more accurately. Call the init function something like "prepareQuery" or "AAA" or "initRememberToCallSaveOrThisWontDoAnything". (The last is an exaggeration, but it might be necessary to make the point).
This is more of a social problem than a technical problem. The interface should make it easy to do the right thing, but programmers do have to know how to use code! Get all the programmers together. Explain simply once-and-for-all this simple fact. If necessary have them all sign a piece of paper saying they understand, and if they wilfully continue to write code which doesn't do anythign they're worse than useless to the company and will be fired.
Fiddle with the way the operators are chained, eg. have each of the intermediateClass functions assemble an aggregate intermediateclass object containing all of the parameters (you mostly do it this was already (?)) but require an init-like function of the original class to take that as an argument, rather than have them chained after it, and then you can have save and the other functions return two different class types (with essentially the same contents), and have init only accept a class of the correct type.
The fact that it's still a problem suggests that either your coworkers need a helpful reminder, or they're rather sub-par, or the interface wasn't very clear (perhaps its perfectly good, but the author didn't realise it wouldn't be clear if you only used it in passing rather than getting to know it), or you yourself have misunderstood the situation. A technical solution would be good, but you should probably think about why the problem occurred and how to communicate more clearly, probably asking someone senior's input.

After great deliberation and trial and error, it turns out that throwing an exception from the Finalize() method was not going to work for me. Apparently, you simply can't do that; the exception gets eaten up, because garbage collection operates non-deterministically. I was unable to get the software to call Dispose() automatically from the destructor either. Jack V.'s comment explains this well; here was the link he posted, for redundancy/emphasis:
The difference between a destructor and a finalizer?
Changing the syntax to use a callback was a clever way to make the behavior foolproof, but the agreed-upon syntax was fixed, and I had to work with it. Our company is all about fluent method chains. I was also a fan of the "out parameter" solution to be honest, but again, the bottom line is the method signatures simply could not change.
Helpful information about my particular problem includes the fact that my software is only ever to be run as part of a suite of unit tests - so efficiency is not a problem.
What I ended up doing was use Mono.Cecil to Reflect upon the Calling Assembly (the code calling into my software). Note that System.Reflection was insufficient for my purposes, because it cannot pinpoint method references, but I still needed(?) to use it to get the "calling assembly" itself (Mono.Cecil remains underdocumented, so it's possible I just need to get more familiar with it in order to do away with System.Reflection altogether; that remains to be seen....)
I placed the Mono.Cecil code in the Init() method, and the structure now looks something like:
public IntermediateClass<T> Init<T>()
{
ValidateUsage(Assembly.GetCallingAssembly());
return new IntermediateClass<T>();
}
void ValidateUsage(Assembly assembly)
{
// 1) Use Mono.Cecil to inspect the codebase inside the assembly
var assemblyLocation = assembly.CodeBase.Replace("file:///", "");
var monoCecilAssembly = AssemblyFactory.GetAssembly(assemblyLocation);
// 2) Retrieve the list of Instructions in the calling method
var methods = monoCecilAssembly.Modules...Types...Methods...Instructions
// (It's a little more complicated than that...
// if anybody would like more specific information on how I got this,
// let me know... I just didn't want to clutter up this post)
// 3) Those instructions refer to OpCodes and Operands....
// Defining "invalid method" as a method that calls "Init" but not "Save"
var methodCallingInit = method.Body.Instructions.Any
(instruction => instruction.OpCode.Name.Equals("callvirt")
&& instruction.Operand is IMethodReference
&& instruction.Operand.ToString.Equals(INITMETHODSIGNATURE);
var methodNotCallingSave = !method.Body.Instructions.Any
(instruction => instruction.OpCode.Name.Equals("callvirt")
&& instruction.Operand is IMethodReference
&& instruction.Operand.ToString.Equals(SAVEMETHODSIGNATURE);
var methodInvalid = methodCallingInit && methodNotCallingSave;
// Note: this is partially pseudocode;
// It doesn't 100% faithfully represent either Mono.Cecil's syntax or my own
// There are actually a lot of annoying casts involved, omitted for sanity
// 4) Obviously, if the method is invalid, throw
if (methodInvalid)
{
throw new Exception(String.Format("Bad developer! BAD! {0}", method.Name));
}
}
Trust me, the actual code is even uglier looking than my pseudocode.... :-)
But Mono.Cecil just might be my new favorite toy.
I now have a method that refuses to be run its main body unless the calling code "promises" to also call a second method afterwards. It's like a strange kind of code contract. I'm actually thinking about making this generic and reusable. Would any of you have a use for such a thing? Say, if it were an attribute?

What if you made it so Init and With don't return objects of type FluentClass? Have them return, e.g., UninitializedFluentClass which wraps a FluentClass object. Then calling .Save(0 on the UnitializedFluentClass object calls it on the wrapped FluentClass object and returns it. If they don't call Save they don't get a FluentClass object.

In Debug mode beside implementing IDisposable you can setup a timer that will throw a exception after 1 second if the resultmethod has not been called.

Use an out parameter! All the outs must be used.
Edit: I am not sure of it will help, tho...
It would break the fluent syntax.

How to release anonymous delegates / closures correctly in C#?

I'm working on a GUI application, which relies heavily on Action<> delegates to customize behavior of our UI tools. I'm wondering if the way we are doing this has any potential issues, e.g. whether the implementation keeps references to captured variables, class instances that declare the delegates etc?
So let's say we have this class MapControl, which wraps a stateful GUI control. The map has different kinds of tools (Drawing, Selection, etc.), represented by ITool interface. You can set the tool with StartTool(), but you can only have one tool active at a time, so when another tool is set previous one is stopped using StopTool(). When tool is stopped, a caller-specified callback delegate is executed.
public class MapControl
{
ITool _currentTool;
Action<IResult> _onComplete;
public void StartTool(ToolEnum tool, Action<IResult> onComplete) {
//If tool is active, stop it first
if (_currentTool != null) StopTool();
_onComplete = onComplete;
//Creates a tool class, etc.
_currentTool = CreateTool(tool) as ITool;
}
public void StopTool() {
//Execute callback delegate
IResult result = _currentTool.GetResult();
if (_onComplete != null)
_onComplete(result);
//Nix the references to callback and tool
_onComplete = null;
_currentTool = null;
}
}
In the application's ViewModel class we set some tool like this:
class ViewModel
{
private MapControl _mapControl = new MapControl();
public void SetSomeTool()
{
//These variables will be captured in the closure
var someClassResource = this.SomeClassResource;
var someLocalResource = new object();
//Start tool, specify callback delegate as lambda
_mapControl.StartTool(ToolEnum.SelectTool, (IResult result) => {
//Do something with result and the captured variables
someClassResource.DoSomething(result, someLocalResource);
});
}
}
In our case the ViewModel class is attached to the main window of a WPF application, and there can only be one instance of ViewModel during the application lifetime. Would it change anything if this weren't the case, and the classes which declare the delegates would be more transient?
My question is, am I disposing of the callback delegates correctly? Are there any scenarios, where this can cause memory bloat by holding on to references it shouldn't?
More generally, what's the safe and correct way of disposing anonymous delegates?

IMHO, it is ok and you are not holding on to any references you don't need. With clearing the references in StopTool you no longer hold them.

You are doing fine with removing the Reference to methods that way.
One more thing you asked:
My question is, am I disposing of the callback delegates correctly?
You don't dispose methods (or pointers to methods for that matter), only classes.

I think a more proper way would be:
_onComplete = (Action<IResult>)Delegate.Remove(null, _onComplete);

If you want to make sure you are disposing correctly of all unused objects, I'd suggest you use tools like the CLR Profiler so that you can have a complete view of how your application is allocating/freeing memory.

Does a lambda create a new instance everytime it is invoked?

I'm curious to know whether a Lambda (when used as delegate) will create a new instance every time it is invoked, or whether the compiler will figure out a way to instantiate the delegate only once and pass in that instance.
More specifically, I'm wanting to create an API for an XNA game that I can use a lambda to pass in a custom call back. Since this will be called in the Update method (which is called many times per second) it would be pretty bad if it newed up an instance everytime to pass in the delegate.
InputManager.GamePads.ButtonPressed(Buttons.A, s => s.MoveToScreen<NextScreen>());

Yes, it will cache them when it can:
using System;
class Program {
static void Main(string[] args) {
var i1 = test(10);
var i2 = test(20);
System.Console.WriteLine(object.ReferenceEquals(i1, i2));
}
static Func<int, int> test(int x) {
Func<int, int> inc = y => y + 1;
Console.WriteLine(inc(x));
return inc;
}
}
It creates a static field, and if it's null, populates it with a new delegate, otherwise returns the existing delegate.
Outputs 10, 20, true.

I was interested by your question because I had just assumed that this kind of thing would always generate a new object and hence to be avoided in code which is called frequently.
I do something similar so I thought I would use ildasm to find out what exactly is going on behind the scenes. In my case it turned out that a new object was getting created each time the delegate was called, I won't post my code because it is fairly complex and not very easy to understand out of context. This conflicts with the answer provided by MichaelGG, I suspect because in his example he makes use of static functions. I would suggest you try it for yourself before designing everything one way and later on finding out that you have a problem. ildasm is the way to go (http://msdn.microsoft.com/en-us/library/f7dy01k1.aspx), look out for any "newobj" lines, you don't want those.
Also worth using CLR Profile to find out if your lambda functions are allocating memory (https://github.com/MicrosoftArchive/clrprofiler). It says it's for framework 2.0 but it also works for 3.5 and it's the latest version that is available.