> Logging sounds like exactly when you want this and why it's useful?
Yes, that is handy… Log($”someValue = {someValue}”) can be Log(labelit(someValue)). That is a small nicety.
> If it's running locally, sure! If you're inspecting logs from a CI system then not so much.
Inspecting logs is a start, but if you don’t bring it back to the code you aren’t solving the problem. So you want a call stack. I agree an enhanced call stack would be even better, and expressions could be a helpful part of that. But CallerArgumentExpression doesn’t seem like a very good way to achieve that. For .net, I guess what you need is the symbol map (.pdb) and source code corresponding to the binary, and a tool to put it together — so that’s all achievable now, without CallerArgumentExpression.
> For .net, I guess what you need is the symbol map (.pdb) and source code corresponding to the binary, and a tool to put it together — so that’s all achievable now, without CallerArgumentExpression.
Sounds like no one needs logs ever again!
“This tool can help you make your logs better”
“But did you know if you do a bunch of work you can have something better than logs?”
This language feature is a small, nice feature. It provides some additional value in numerous common use cases. It may be superseded by other things that an individual may or may not have tooling support for.
Never mind that for a test log with numerous failures you’d need to generate a .dmp per failure. And each .dmp needs to be individually opened, run, and analyzed. So even if you had this you still probably want as much information as is possible in the log. It’s not like this is an either-or thing. You can have both!
As I read it, it's more than that - you get to see the expression passed as an argument.
If they would bake in that expression within NullReferenceException, well that would be so good... because there are methods that contain dozens of lines and that particular exception can happen almost anywhere. Usually I'm considering that when writing code and thinking: well this method can't throw NullReferenceException, just to be greeted with that particular exception at runtime, ugh.
> If they would bake in that expression within NullReferenceException, well that would be so good...
CallerArgumentExpression doesn't do that, though.
I think you could maybe use it to do something explicit, like...
someexpr.CheckNotNull().DoSomethingWithSomeExpr()
where CheckNotNull() somehow uses CallerArgumentExpression to capture "someexpr" so that if someexpr was null, the exception could include the actual expression in the exception message. But that means decorating code with CheckNotNull() all over the place, which really limits this.
What you really want here is a good call stack -- maybe with expressions, source lines, local variable values, etc.
Logging sounds like exactly when you want this and why it's useful?
> is examine the code on the call stack anyway
If it's running locally, sure! If you're inspecting logs from a CI system then not so much.
Honestly I wish printing a callstack which also dump all stack variables. Including recent expression sounds pretty nice.
Lord knows how many times I've gone back to add gratuitous logs because some Python script threw an exception and the callstack alone wasn't enough.