adding a base record for exception

[Mr0N]

I suggest adding a base record for exception
Similar to this https://github.com/Mr0N/CustomExceptionRecords

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[antomys]

Well, it doesn't make sense. Frankly speaking, you reinvented System.Exception class.

[Mr0N]

Well, it doesn't make sense. Frankly speaking, you reinvented System.Exception class.

for record

[antomys]

Could you define, what is a major difference between record and class?

[stephentoub]

It sounds like what you're really asking for is the ability to declare a record that derives from Exception. That's an issue for dotnet/csharplang, the ability to derive a record from a non-record.

[Mr0N]

Could you define, what is a major difference between record and class?

The record can be written much faster and can be wtites into one file.

[Mr0N]

It sounds like what you're really asking for is the ability to declare a record that derives from Exception. That's an issue for dotnet/csharplang, the ability to derive a record from a non-record.

This is a runtime problem, because I implemented it without changing the programming language.

[stephentoub]

This is a runtime problem, because I implemented it without changing the programming language.

RecordException would need to derive from Exception. And if that were possible, you wouldn't need RecordException at all, as any record could derive from Exception directly.

"record" is a construct of the C# language. Augmenting its design and capabilities are the domain of the C# language.

[antomys]

It sounds like what you're really asking for is the ability to declare a record that derives from an Exception. That's an issue for dotnet/csharplang, the ability to derive a record from a non-record.

Oh, I see. Thanks for elaborating. So the main suggestion of this issue shortens to "Add ability to inherit a record from a non-record (here in issue: record from class)). So, as I see it, this issue is not an issue, but a suggestion. Not sure that it's going to be useful, but anyway

[Mr0N]

This is a runtime problem, because I implemented it without changing the programming language.

RecordException would need to derive from Exception. And if that were possible, you wouldn't need RecordException at all, as any record could derive from Exception directly.

"record" is a construct of the C# language. Augmenting its design and capabilities are the domain of the C# language.

This is a runtime problem, because I implemented it without changing the programming language.

RecordException would need to derive from Exception. And if that were possible, you wouldn't need RecordException at all, as any record could derive from Exception directly.

"record" is a construct of the C# language. Augmenting its design and capabilities are the domain of the C# language.

Well, change the logic of work "throw" and make a basic type for excluding records

[Mr0N]

[Mr0N]

It sounds like what you're really asking for is the ability to declare a record that derives from an Exception. That's an issue for dotnet/csharplang, the ability to derive a record from a non-record.

Oh, I see. Thanks for elaborating. So the main suggestion of this issue shortens to "Add ability to inherit a record from a non-record (here in issue: record from class)). So, as I see it, this issue is not an issue, but a suggestion. Not sure that it's going to be useful, but anyway

Yes, I do it at the level of il code, but in my example it will not be possible to do this in C# code.

[stephentoub]

Well, change the logic of work "throw" and make a basic type for excluding records

Again, that's the C# language. The runtime supports throwing anything.

This is not actionable here. I'm going to close it. Thanks.

[Mr0N]

Reference

So my library changes the programming language :)

[HaloFour]

The limitation is that C# does not allow records to extend from non-records (other than System.Object), but all exceptions must extend from System.Exception. I would imagine that if the language team were to revisit this they would do so through lifting the limitation on inheritance in general vs. doing something general purpose for exceptions.

See: https://github.com/dotnet/csharplang/blob/f856ab390d974896079905ef38479e00a54c5025/meetings/2020/LDM-2020-06-22.md#inheritance-between-records-and-classes

[Mr0N]

And at the same time add the il code project

[HaloFour]

This is why I'm suggesting that if this is considered that it would be addressed by lifting the limitation, allowing records to extend from other arbitrary classes. Then a record could extend from System.Exception directly. It wouldn't be trivial, but it's much more likely to happen than to have a new base exception class.

[Mr0N]

This is why I'm suggesting that if this is considered that it would be addressed by lifting the limitation, allowing records to extend from other arbitrary classes. Then a record could extend from System.Exception directly. It wouldn't be trivial, but it's much more likely to happen than to have a new base exception class.

It's bad, it's better to change the programming language, or to write one class in il, which is easier?

[HaloFour]

Either way the programming language would change because RecordException would have to derive from Exception, which is not legal in C#. But by adding that one class all you've done is split the exception hierarchy since these record exceptions cannot extend from any of the common base exceptions defined in the BCL, like ArgumentException or IOException.

[Mr0N]

Either way the programming language would change because RecordException would have to derive from Exception, whic

Yes, but from this record, only records will be followed, it will have a base class Exception, the programming language at the C# level is not affected, because it is written in il code, a basic record for errors just appears.

[Mr0N]

extend from any of the common base exceptions defined in the BCL, like ArgumentException or IOException.

I don't see the point of them imitating records, in fact a base class for records is needed to reduce the routine of writing classes for errors

[HaloFour]

Yes, but from this record, only records will be followed, it will have a base class Exception, the programming language at the C# level is not affected, because it is written in il code, a basic record for errors just appears.

The BCL is written in C#, if C# doesn't allow it then it won't end up in the runtime. They have already closed your suggestion of adding a new base exception class as something they won't do.

I don't see the point of them imitating records, in fact a base class for records is needed to reduce the routine of writing classes for errors

Which just makes them that much less useful.

[Mr0N]

The BCL is written in C#, if C# doesn't allow it then it won't end up in the runtime. They have already closed your suggestion of adding a new base exception class as something they won't do.

[HaloFour]

@Mr0N

You'll also notice this:

They've already stated that this is a language concern, and as a language concern the possible solution would be to lift the limitation on extending non-records.

The runtime team has expressed being not interested in writing custom IL for specific APIs that cannot be expressed in C#, such as defining helper methods that used System.Delegate or System.Enum constraints.

[Mr0N]

https://github.com/dotnet/runtime/blob/d459c65324aa3387252d480781e9c7ea6f934231/src/tests/JIT/opt/JitMinOpts/Perf/BBCnt1.il

[HaloFour]

That's a test.

This was transferred to the C# repo for a reason, it's a language issue. If you're stuck on this being implemented as a special new class you're going to be disappointed.

[Mr0N]

@Mr0N

You'll also notice this:

They've already stated that this is a language concern, and as a language concern the possible solution would be to lift the limitation on extending non-records.

The runtime team has expressed being not interested in writing custom IL for specific APIs that cannot be expressed in C#, such as defining helper methods that used System.Delegate or System.Enum constraints.

well, I don't know, well, maybe it's a problem of the programming language that needs to be implemented on the il code, just allow them to do it.

[stephentoub]

You're trying to use a feature of the C# language: records. You don't like a limitation of that C# feature: records currently can't derive from non-records. The fix isn't to special-case a single base type in the core libraries and hack it outside of C# to work-around the designed C# constraint for that one case. You're asking for a custom Exception base type, but there are thousands and thousands of other classes that folks might similarly want as a base type for a record; Exception is not special in that regard. Thank you for your suggestion, but we're not going to add such a type to the base libraries.

In the meantime, you've hacked up an approach in IL that obviously meets your needs, since you're asking us to replicate what you've done. You're obviously free to use that as a helper in your own projects, and even to publish a NuGet package for others to consume if you believe it's so impactful. In the meantime, I'd encourage you to have the conversation at the language level about lifting the constraint, and more importantly, how to address the holes that constraint is there to prevent.

Thanks.

[Mr0N]

You're asking for a custom Exception base type, but there are thousands and thousands of other classes that folks might similarly want as a base type for a record;

well, they won't be able to do it (it's good, because these are fundamentally different things, I just don't see the second solution), this record will be an ordinary record, besides, it will be accepted by throw

[Mr0N]

Okay, this is just an idea, if you don’t want to implement it, I’ll use the library maybe)

[Mr0N]

This sounds like a better use case for primary constructors then, not records.

I did not understand what it is, I doubt that it will be implemented, the records already exist.

[Mr0N]

do not like

[HaloFour]

Primary constructors are championed by the language team and it has been triaged into the working set. It's a lot easier and more likely to happen then extending records to allow them to extend non-records, especially since you don't care about value equality.

[Mr0N]

Primary constructors are championed by the language team and it has been triaged into the working set. It's a lot easier and more likely to happen then extending records to allow them to extend non-records, especially since you don't care about value equality.

Well, if it can be done that way,
record MyException(string message):RecordException(message);
and it will be done in one string,.and it will be in C# 12, then I'm in favor

[DavidArno]

Primary constructors are championed by the language team and it has been triaged into the working set. It's a lot easier and more likely to happen then extending records to allow them to extend non-records, especially since you don't care about value equality.

Well, if it can be done that way, record MyException(string message):RecordException(message); and it will be done in one string,.and it will be in C# 12, then I'm in favor

No, it won't be done in that way as they won't be records. The syntax is still in discussion, but it will let you write something like:

class MyException(string message) : Exception(message);

This appears to be what you are asking for here: the ability to create a custom exception declaration on one line.

There's also no guarantee that it'll make it into C# 12. It might be in v13; it might never happen. There are no guarantees of what will make the cut for future versions of the language.