|
|
Seriously, I'm going to have to do a bit of research as my present job involves *preventing* that kind of thing....
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
Dave Kreskowiak wrote: The C# script would be compiled and executed without generating an .EXE on disk. It would all be in-memory.
Pretty sure you could have done that since C# 1.0. And you can certainly do it now.
You create the code.
You compile the code into a 'file' which is actually just a hunk of memory. That is the "dll"
You then run the code in the "dll"
|
|
|
|
|
Yep, and it was ugly and included certain restrictions on how the code had to be written.
|
|
|
|
|
Dave Kreskowiak wrote: Yep, and it was ugly and included certain restrictions on how the code had to be written.
I would need more details. How the code and not for example process failures would lead to problems.
I have worked on two products in C# that did dynamic code compiling. Certainly no restrictions that ever stopped what I wanted to do or in one case many customers that were using the product to write code, for the actual code.
I didn't try to keep it in memory but the dlls were loaded dynamically in both cases. So converting to memory for that part would have been easy.
Now the entire process is "ugly" but in both cases there was much of what was done that could not have been done, in a product feature way, that would have removed that requirement.
In both cases people tended to get excited and then over use it. I have done the same with java (at least 3 times) and that problem happens with that as well. However that is a process problem not a code problem.
So in C# does it have to do with actually saving it to memory?
|
|
|
|
|
You're thinking in technical terms.
My issues with the previous ways of doing it are more "customer" issues than anything technical.
|
|
|
|
|
Noticed that too during my escapades with VS Code and .NET Core 6.0 on Zorin OS last thursday.
But at the end of the day I was glad I got the example working ...

|
|
|
|
|
You were able to install VS Code & dotnet core SDK etc on Zorin and create & compile a C# program on that OS?
Very interesting.
|
|
|
|
|
Yes, but Zorin OS Lite was apparently not a good choice for bleeding edge things like .Net Core 6.0.
Things probably would have been easier on the newer Zorin OS full version using the "Snap package manager".
Btw. in this video the new and strange ways of .NET Core 6.0 are explained:
Hello World: .NET 6 and .NET Conf - YouTube[^]
|
|
|
|
|
Thanks for the link directly to that section of that longer video.
that was great addt'l info on this.

|
|
|
|
|
|
Super Lloyd wrote: .NET.. err.. 4.7?
The version of .NET is irrelevant; it's the compiler and language version that matters. The compiler turns local functions into code that would work in pretty-much any version of .NET - either static functions, instance functions, or functions on a closure class, depending on what you've referenced in the local function.
Eg:
void Foo()
{
int Bar() => 42;
Console.WriteLine(Bar());
} becomes something similar to:
[CompilerGenerated]
internal static int <Foo>g__Bar|0_0()
{
return 42;
}
void Foo()
{
Console.WriteLine(<Foo>g__Bar|0_0());
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I think they are going after two main areas: be more like python (REPL approach) and be more like node (see the new asp.net 6 project templates).
Eusebiu
|
|
|
|
|
BASIC -> QBASIC -> VisualBasic -> C# -> BASIC -> ... VB7?
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
That's a simple continuation of the "pay for play" philosophy. While the unavailability of the Main function is a thing I really hate about Python (how the hell am I supposed to know where complex code starts operating), it's absence is a huge win for small code bases.
Don't get me wrong, for a kLoC of code, spread across 4 or so different modules, the lack of structure which this particular C# template brings to the table would be a bloody nightmare (which is why I'm not using this style for my kLoC-multimodule project). But for something of only mild complexity, that's a win.
Boilerplate code, like any other overhead, starts paying off eventually, but if you have something not nearly huge enough for that overhead to pay off, low-overhead alternatives rule.
Take file system as an example. NTFS (or ext, if you're so inclined) is by orders of magnitude more advanced, than FAT. Yet, FAT (be it FAT32 or exFAT) got it's own raison d'etre, which is low-requirements-low-overhead.
PS: that part that you highlighted, namely local functions, is older, than .NET 6. They started with C# 7.0 which started it's life with .NET 4*x.
|
|
|
|
|
There are a number of shorthand changes (but little innovation) that have been made to C# over the years that are of limited or questionable value. It is a good idea to test out these shorthand C# changes, then look at what the compiler does with them by looking at the generated MSIL. As one example, having done that, it is why I no longer use "using" for IDisposable objects.
If you like a particular shortcut, use it. But my advice is to at least know what the compiler does with it. In the case of the OP, just make your own Main() and go with it.
|
|
|
|
|
Could you expand on what you meant by the using example? From what I can see, these end up equivalent:
using (SomeResource res = new SomeResource())
{
}
SomeResource res = new SomeResource();
try
{
}
finally
{
if (res != null)
((IDisposable)res).Dispose();
}
which seems right to me.
|
|
|
|
|
In short, the using statement swallows constructor errors. Since the actual code being executed is a try … finally, why not just use try … finally (or better yet, try… catch … finally) and use your own code for capturing and logging all exception? And given the unpredictability of the GC, scalability is better served by following the principle, “if you create an object, clean it up when done with it”. Relying on the GC and using shortcuts like the using statement are things I consider poor engineering choices in the context of the SDLC. Others may disagree, but I have yet to see a reasoned argument against my approach that ends in better software.
|
|
|
|
|
Aah, ok. I can understand not wanting to use the pattern if you need to catch exceptions or heavily expect that you will need to in the future with that class (if you're gonna have to expand the using into a try...catch anyways might as well go ahead and do it).
That being said, if the exceptions happen in the constructor, they will not be swallowed since object creation happens outside of the try...finally . The only exceptions that would be swallowed are the ones that occur while using the object.
Tested using:
class Test : IDisposable
{
public Test() => throw new NotImplementedException();
public void Dispose() {}
}
using (Test t = new Test())
{
Console.WriteLine("constructor exception swallowed.");
}
|
|
|
|
|
I did a demo on this about 1-1/2 years ago, as my fellow developers didn’t see the harm, either. They did afterwards.
Since in a well designed app, the try-catch-finally is mostly copy and paste, it really does not save any meaningful development time to use the using statement.
Exception handling is a key to reducing dev and QA testing, as well as production troubleshooting. By utilizing the exception’s Data collection, the developer can capture runtime values that are very helpful in diagnosing problems in execution. I have, on many occasions, seen production troubleshooting that would have taken a day or more, shortened to minutes, by smart exception handling. In many production systems, that difference in time can mean thousands to millions in revenue losses avoided by significantly quicker resolution.
Using us a shortcut that alleviates the burden of a developer having to remember to call Dispose(). I’d rather use developers who don’t need such shortcuts.
|
|
|
|
|
I view it as more of an option to reduce code noise in specific circumstances. I don't disagree with your examples but I don't see the path to the conclusion of inherent harm.
Playing devil's advocate on myself, I can see the argument that maybe the class itself won't throw once constructed but something could go terribly wrong with the resource. On the one hand if that's somewhat expected like with a network connection, I can see the merit in saying using would be harmful for the reasons you've stated. On the other hand, if errors in the resource are unrecoverable at this layer, then I would argue using explicitly states your expectation - this code should not throw and if it does something has gone horribly wrong we can't recover from here so let the exception propogate upwards. In this situation the whole point is the finally block, not the exception handling.
I agree it can be misused but non-recovering catch es are often misused by improperly re-throwing and losing stack-trace information. I still see the value in re-throwing though if you want to add explicit information to the exception's data to help with debugging.
|
|
|
|
|
A using block does not swallow exceptions, any more than a try..finally would.
The only time an exception would be lost would be if your Dispose method throws an exception. Whilst that's not entirely unheard of, it's a sign of a poorly implemented class, not a reason to reject the using block outright - especially since you'd have exactly the same problem with a try..finally block.
Code written with a using block is going to be significantly more "correct" than code that eschews it in favour of manual clean-up.
Maybe you should post your demo code to try to convince us.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Quote: Code written with a using block is going to be significantly more "correct" than code that eschews it in favour of manual clean-up.
That comes across as more religion than a rational approach.
In order to illustrate my point, I can add the C# code I used for the test (in .NET 6.0) and the MSIL output of both. The unit test for the "using" statement took 28 ms, while the standard use took 18 ms. The MSIL for the "using" statement produced 47 lines of MSIL code, while the standard approach without "using" produced 31 lines of MSIL code.
I kept the IDisposable instance simple for this example.
In order to capture the constructor exception, the using block has to be wrapped with a try-catch.
The results of this test, combined with how I capture exception data and the runtime values associated with the exception (to significantly reduce support costs of the SDLC), is why I do not use the "using" statement in production apps. I do use it where appropriate in proof-of-concept and personal utilities, where support and performance is less of a concern.
IDisposable class:
namespace UsingTest
{
public class DisposableClass : IDisposable
{
private Boolean m_blnDisposeHasBeenCalled = false;
public DisposableClass()
{
Int32 denom = 20;
Int32 numer = 0;
Int32 result = denom / numer;
}
public String WhoIsIt()
{
return $"{Environment.UserDomainName}\\{Environment.UserName} on {Environment.MachineName} from {Environment.CurrentDirectory} on thread ID {Environment.CurrentManagedThreadId.ToString()}.";
}
#region IDisposable Implementation
public void Dispose()
{
try
{
if (!m_blnDisposeHasBeenCalled)
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
catch (Exception exUnhandled)
{
exUnhandled.Data.Add("m_blnDisposeHasBeenCalled", m_blnDisposeHasBeenCalled.ToString());
throw;
}
}
~DisposableClass()
{
Dispose(false);
}
public void Dispose(Boolean disposing)
{
try
{
m_blnDisposeHasBeenCalled = true;
}
catch (Exception exUnhandled)
{
exUnhandled.Data.Add("m_blnDisposeHasBeenCalled", m_blnDisposeHasBeenCalled.ToString());
throw;
}
}
#endregion IDisposable Implementation
}
}
Unit test with the "using" statement
[TestMethod]
public void UsingStatementTest()
{
try
{
using (DisposableClass test = new())
{
try
{
String result = test.WhoIsIt();
}
catch (Exception ex)
{
Assert.Fail($"INNER: {ex.Message}");
}
}
}
catch (Exception exOuter)
{
Assert.Fail($"OUTER: {exOuter.Message}");
}
}
Unit test with a standard approach:
[TestMethod]
public void StandardUsageTest()
{
DisposableClass test = null;
try
{
test = new();
String result = test.WhoIsIt();
}
catch (Exception exOuter)
{
Assert.Fail($"ONLY: {exOuter.Message}");
}
finally
{
test?.Dispose();
}
}
MSIL from the "using" statement text method:
.try
{
IL_0000: newobj instance void [UsingTest]UsingTest.DisposableClass::.ctor()
IL_0005: stloc.0
.try
{
.try
{
IL_0006: ldloc.0
IL_0007: callvirt instance string [UsingTest]UsingTest.DisposableClass::WhoIsIt()
IL_000c: pop
IL_000d: leave.s IL_0027
}
catch [System.Runtime]System.Exception
{
IL_000f: stloc.1
IL_0010: ldstr "INNER: "
IL_0015: ldloc.1
IL_0016: callvirt instance string [System.Runtime]System.Exception::get_Message()
IL_001b: call string [System.Runtime]System.String::Concat(string,
string)
IL_0020: call void [Microsoft.VisualStudio.TestPlatform.TestFramework]Microsoft.VisualStudio.TestTools.UnitTesting.Assert::Fail(string)
IL_0025: leave.s IL_0027
}
IL_0027: leave.s IL_0033
}
finally
{
IL_0029: ldloc.0
IL_002a: brfalse.s IL_0032
IL_002c: ldloc.0
IL_002d: callvirt instance void [System.Runtime]System.IDisposable::Dispose()
IL_0032: endfinally
}
IL_0033: leave.s IL_004d
}
catch [System.Runtime]System.Exception
{
IL_0035: stloc.2
IL_0036: ldstr "OUTER: "
IL_003b: ldloc.2
IL_003c: callvirt instance string [System.Runtime]System.Exception::get_Message()
IL_0041: call string [System.Runtime]System.String::Concat(string,
string)
IL_0046: call void [Microsoft.VisualStudio.TestPlatform.TestFramework]Microsoft.VisualStudio.TestTools.UnitTesting.Assert::Fail(string)
IL_004b: leave.s IL_004d
}
MSIL for the unit test of the standard approach:
.try
{
.try
{
IL_0002: newobj instance void [UsingTest]UsingTest.DisposableClass::.ctor()
IL_0007: stloc.0
IL_0008: ldloc.0
IL_0009: callvirt instance string [UsingTest]UsingTest.DisposableClass::WhoIsIt()
IL_000e: pop
IL_000f: leave.s IL_0033
}
catch [System.Runtime]System.Exception
{
IL_0011: stloc.1
IL_0012: ldstr "ONLY: "
IL_0017: ldloc.1
IL_0018: callvirt instance string [System.Runtime]System.Exception::get_Message()
IL_001d: call string [System.Runtime]System.String::Concat(string,
string)
IL_0022: call void [Microsoft.VisualStudio.TestPlatform.TestFramework]Microsoft.VisualStudio.TestTools.UnitTesting.Assert::Fail(string)
IL_0027: leave.s IL_0033
}
}
finally
{
IL_0029: ldloc.0
IL_002a: brfalse.s IL_0032
IL_002c: ldloc.0
IL_002d: call instance void [UsingTest]UsingTest.DisposableClass::Dispose()
IL_0032: endfinally
}
|
|
|
|
|
MSBassSinger wrote: That comes across as more religion than a rational approach.
Says the person trying to convince me that a using block swallows exceptions, whilst showing no evidence of it doing so.
MSBassSinger wrote: The unit test for the "using" statement took 28 ms, while the standard use took 18 ms.
So code with different behaviour, compiled in a debug build, has approximately 10ms difference in your tests?
Aside from the issue of micro-optimisation - any extra overhead from the using construct will be dwarfed by the cost of your real code - a unit test is not suitable for micro-benchmarks. You need to "warm up" your code, then measure performance over thousands of runs to get a meaningful result. Try using BenchmarkDotNet[^] to measure the code instead.
And while you're at it, fix your tests so that you're comparing the same - or at least comparable - code. Change your "standard" test to:
public void StandardUsageTest()
{
try
{
DisposableClass test = null;
try
{
test = new();
try
{
String result = test.WhoIsIt();
}
catch (Exception ex)
{
Assert.Fail($"INNER: {ex.Message}");
}
}
finally
{
test?.Dispose();
}
}
catch (Exception exOuter)
{
Assert.Fail($"OUTER: {exOuter.Message}");
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I am sorry you do not fully understand what I wrote.
First, I did show that constructor exceptions are "swallowed", though I do admit that is a subjective term. To be more precise, constructor exceptions occur outside the MSIL exception handling. In order to catch the constructor exception, the "using" has to be wrapped in a try-catch of its own.
Second, because of what I just explained, the unit test that implements "using" needs the outer try-catch, while the other approach does not. The "using" approach results in nested try-catches, which is why it creates more lines of code to be executed. The coding for the unit tests is correct "as-is". The outer try-catch in your version of the StandardUsageTest() method is unnecessary.
Third, the execution time is not the point. I ran them several times, to account for any caching, and the time relationship remains the same. The point is that a very popular C# coding shortcut results in more lines of code to be executed (MSIL) than the other approach, and forecloses the opportunity to capture runtime values in the exception's Data dictionary within the MSIL code.
If you want to stick with the "using" statement, then do so. I am not trying to tell you or anyone else what they should do. I am presenting information for the "what" and "how" so that an objective person can decide for themselves. I provided the details, as was asked, and it completely and rationally supports my thesis. If you agree, fine. If you disagree with rational reasons you can explain, then educate us all. But since you are disagreeing without a rational basis, that is fine. You should continue to do things the way you think is best. But if you don't like my approach, just admit it is a personal preference to stick with the "using" statement. For example, if benefitting from more advanced exception handling does not provide a value for you, then implementing the "using" statement makes sense.
|
|
|
|
|