I'm a couple of episodes in on #Ironheart on #DisneyPlus and loving it. Dominique Thorne is great. I'm sure there are some die hard Marvel fans finding something to complain about, but I couldn't give a hoot.
| GitHub | https://github.com/Jawvig |
Josh G
@Josh_Gallagher@techhub.social
- 61 Followers
- 163 Following
- 782 Posts
Microsoft IT Consultant, Omnics Ltd. Tech Director at Matchnet Ltd. Programmer at heart. Bit of a thing for #AzureFunctions and #dotnet. #CSharp is my home, but dabble in #Python, #JavaScript (and management). Loving #Pulumi too.
TIL: "e.g." is not "exempli gratis", which I was translating as "free example", but "exempli gratia" which I am gathering is something more like "a good-will example". Health warning: I studied Latin for 6 weeks for half an hour a week. I remember nothing of it..
Khalid K-1000 🤖Hey #dotnet folks, if you're running in a cloud environment, be careful upgrading to the latest version of .NET 8.0.17 before double-checking your forward headers configuration and proxy settings. You may have a misconfigured app, but it's been working up to now.
Boost to let others know. Cheers.
@wackJackle Where did you grab the screenshot from?
@mihamarkic Jolly good questions, and shows up that I hadn't thought that through! I'd guess the answer to both is `default(int)` , i.e. zero. But that does smell quite bad and I can see that as being a big reason to say no to my proposal. It'd be especially bad for non-nullable reference types where `nullable` was enabled, as they'd either end up with a null value at run time or the compiler would have to insist on only nullable reference types getting created between the `try` and `catch`. Okay, I take it all back. Terrible idea!!
@CriticalSilence Just for interest, the impetus for writing this proposal was that for the umpteenth time I found myself extracting the contents of one method into another so I could put a try...catch around the whole thing without indenting everything further. The context here is if *anything* goes wrong in the method, I need to stop the exception bubbling so I can return an explicit failure from the method and thereafter refund a payment. My default design position is top level exception handling, but there are some places where you do need different behaviour for resilience.
@CriticalSilence I see your points, but personally they don't bother me. On the first one, people can (and do) already use try-catch too much. I don't really think this makes it all that much easier to misuse, but it's subjective and we may have to disagree on that.
On the second point, I view it as similar to the `using` and `namespace` declarations versus their statement equivalents. I will concede that the difference here is that the scope of the application can be foreshortened by a `catch` or `finally`, where `using` and `namespace` declarations are until the end of the method of file respectively. We seem okay with these not having a statement block with indented code, so why should `try` be different?
That last point begs a rebuttal that you could start levelling the same arguments for `if`, `else` and probably other constructs that are followed by statement blocks, and that would clearly be absurd. But I still think `try` is different enough that this would be okay.
@mihamarkic It would be a `try` declaration rather than statement, so there's no enclosing statement block to limit the scope of the variables.
`try;`
`var x = 3;`
`catch (Exception e) => _logger.Debug(x);`
`Console.WriteLine(x);`
I don't think there's any IL reason why the variables would need to be scoped to inside a try block. The emitted IL would indicate that the set of instructions protected by the `try;` declaration would comprise everything from there to the `catch` (or `finally` or end of the method / statement block). That shouldn't have any bearing on variable scope. However, getting the variables into the lamda for the `catch` will still be via capture. The `Console.WriteLine(x)` in the example above should still execute fine even though outside of the set of statements protected by the `try;`. No need to declare an uninitialized or dummy variable value outside of the block:
`int x = Int32.MinValue;`
`try {`
`x = 3;`
`}`
`catch (Exception e) { _logger.Debug(x); }`
`Console.WriteLine(x);`
`try;`
`var x = 3;`
`catch (Exception e) => _logger.Debug(x);`
`Console.WriteLine(x);`
I don't think there's any IL reason why the variables would need to be scoped to inside a try block. The emitted IL would indicate that the set of instructions protected by the `try;` declaration would comprise everything from there to the `catch` (or `finally` or end of the method / statement block). That shouldn't have any bearing on variable scope. However, getting the variables into the lamda for the `catch` will still be via capture. The `Console.WriteLine(x)` in the example above should still execute fine even though outside of the set of statements protected by the `try;`. No need to declare an uninitialized or dummy variable value outside of the block:
`int x = Int32.MinValue;`
`try {`
`x = 3;`
`}`
`catch (Exception e) { _logger.Debug(x); }`
`Console.WriteLine(x);`
@CriticalSilence Top level exception handling basically is a massive try catch block,and a common pattern. I don't think what I am suggesting makes it easier to write try catches, but it stops make the code more less messy, I think.
I see there are various similar proposals, including the catch lambda. They're not exactly the same (see https://github.com/dotnet/csharplang/discussions/9293 and linked issues), but the criticism seems to be to do with nested try..catch considerations. Not sure if my proposal gets around that. I'll need to dig deeper. I feel like disallowing any more `try` keywords in the same method ought to resolve any issues, but I understand this might feel a bit hacky.
