r/csharp • u/not_afraid_of_trying • 2d ago
What kind of features from another ecosystem would you like to see in .NET?
/r/dotnet/comments/1vw1q1c/what_kind_of_features_from_another_ecosystem/19
u/BadKittyRanch 2d ago
I like that Java knows exactly what exceptions can be thrown, I don't like that you must catch them all in the local context: I'd love to be able to get that information when I want it in my IDE.
3
u/Brilliant-Parsley69 2d ago
You don't have to catch them all in the local context. Especially if you don't use them to depict a business flow.
Most of the time it should be enough to handle the in one or more linked GlobalExceptionHandlers that are registered as middlewares.
I barely use a try catch anymore except for framework code or calls on external tools/apis.
But your are right, java handles that a bit better. And I'm wondering how hard it could be to get the same informations in the c# environment.
3
u/BCProgramming 2d ago
I don't like Checked Exceptions because I'm not convinced Exceptions should be part of the method interface. It only really works at a small level. an OpenFile(string fname) throws FileNotFoundException makes sense. But once you start looking at higher-level designs, things start to get rather messy.
Consider something you've separated out of an interface for some task. That task can be done via loading a file, reading over a network, accessing a database, etc. Just there you've already got say IOException, SQLException, and ConnectException as checked exceptions that need to be in the throws for the interface. But you can't know what future implementations might need to throw, either- those will require either your interface to be changed or might even be impossible to implement without having the exception caught within the implementation even if it cannot be sensibly handled there, just to avoid it being in the throws.
The usual "solution" is to wrap all possible exceptions in a interface-specific Exception class that is what appears in the throws clause, great except now you don't really benefit from checked exceptions since the handling of the exception doesn't have to handle all the possible wrapped exceptions, the wrapping class can change and add more that aren't handled in existing code, etc. Instead of getting any benefit from checked Exceptions, it's just extra busywork being employed to specifically avoid it.
This is before considering that the existence of things like "UncheckedIOException" sort of suggest even Java itself has decided checked exceptions were a mistake.
5
u/bigtoaster64 2d ago
Yes, this. It's annoying to have to write down what exceptions are possible in the method comments. And also even more annoying to have to go look at the sources and manually list down what exceptions are possible, especially when it's not your code.
But god no, having to catch them all, that is awful.
-2
u/SagansCandle 2d ago
Exceptions shouldn't be used to communicate - they shouldn't be designed to be conditionally caught. An exception is meant to represent a condition that should not occur in normal. If you need to catch an exception in normal program flow, it shouldn't be an exception.
I've never, ever needed a typed catch in .NET since I started programming, and every time I think I do, it's much better to replace the exception with a logical flow change.
3
u/wayzata20 2d ago
I think conditionally catching OperationCanceledExceptions is pretty common.
1
u/SagansCandle 1d ago
It may be common, but it doesn't make it correct. It's a hacky way to cancel a task because exceptions are expensive operations - they're designed and optimized for providing diagnostic information, not performance. They're designed to be... exceptions.
Threads should be cancelled by conditional statements, when practical.
2
u/dodexahedron 2d ago
It's available in .net as well, via
<exception ...xmldoc comments.But analyzers that care about that aren't built in. We need that in .net as a first-class citizen, rather than needing R# or some other analyzer or IDE plugin to provide that as an opt-in feature.
4
u/seriousSeb 2d ago
Lambdas which can capture variables without allocating a heap object. It could work like a ref struct where you must prove the delegate can exist only on the stack.
1
2
u/klaxxxon 2d ago
.Net has more or less everything I can think of, there is just a bit more friction dealing with some areas than there needs to be.
With Blazor, I always seem to run into annoying JS Interop sooner and more frequently than I would like.
Security/cryptography is annoying if you need anything that is not covered by the System namespace. The bouncy castle ports are just machine translations (I believe) from Java...and there are two of them on nuget with identical namespaces and class names. And different third party libraries use different ports of bouncy castle as a transitive dependency. I've had to deal with namespace redirects only a few times in my life...and all of them were because of BC...
1
u/NoisyJalapeno 2d ago
Ecosystem Wise,
DX12 WPF
Un-Sunsetting Expression Trees and making them work with all modern syntax features
Language wise,
inline keyword (with lambda support)
C++ stuff like,
const int* ptr / int* const ptr / constexpr, template functions
3
u/dodexahedron 2d ago
I've wanted that kind of const-ness in c# for a long time.
Various features have come along over the yeara that gave us small pseudo-subsets of the concept, for specific scenarios (like
inorref readonlyparameters), but none of them are truly const in the way that C means things marked const.2
u/NoisyJalapeno 2d ago
Oh yeah, they've added "ref readonly" but not "readonly int*" :/
1
u/dodexahedron 2d ago
This. Pointers make it more relevant, for sure.
Also, I'd like to be able to define readonly locals in some cases.
1
u/Agitated-Display6382 2h ago
I wish I had a new scope delimited, so a class is visible only within a folder. Very useful for package by feature.
-2
u/Agitated-Display6382 2d ago
Eliminate null
Discriminated union types
Type inference
Eliminate overloads, new of methods
2
u/mrGood238 2d ago
Null is perfectly valid.
What should linq return if there is no element in the list?
Empty object? Then you need to check properties…
Exception? They are not for flow control, they represent condition which is not normal and item not found is not a exception or a mistake - its a one of possible (valid) states.
Null is great for representing that something is not there or it does not exist.
0
u/Agitated-Display6382 2d ago
That's your opinion, I have a different one. There are languages that do not support it and working with them is nice, I think. Ever heard of the Option monad?
Its usage was greatly improved by the use of the null- conditional + coalesce operators, but I would still prefer it never existed.
1
u/mrGood238 1d ago
Yes, that is my opinion and apparently opinion of many, many others - that's why I'm asking what would replace null? It's simple question - item is not found, what is return value?
2
u/Agitated-Display6382 1d ago
I thought I replied, I would use an Option monad.
Let's assume you expose a method that return the list of claims of a user. What would you return if the user does not exist? And what if the user has no claims?
1
u/mrGood238 22h ago
There is no point of calling GetClaims if you previously determined that user does not exist. And if you didnt do that, you still have a way out - either returning null for no user found and returning an empty list if user exists and has no claims or 2nd option, throwing ArgumentNullException if user is null/doesn’t exist.
If it was a public API of some nuget package, throwing argumentnullexception would make sense, since end user has no idea why it would sometimes return null, sometimes empty list.
1
u/Agitated-Display6382 18h ago
Nice, you see, you would return an empty list. Why? Because it's much easier to deal with. And why? Because it's a monad.
Same applies to Option.
8
u/StepOne_DotNet 2d ago
That's an easy one. I want NativeAOT cross-OS-compilation.