Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mono: Replace exception strings with those stored in the resx file (#34056) #78341

Merged
merged 25 commits into from
Mar 23, 2023

Conversation

databunks
Copy link
Contributor

@databunks databunks commented Nov 14, 2022

Fixes #34056

@dotnet-issue-labeler
Copy link

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

@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Nov 14, 2022
@dnfadmin
Copy link

dnfadmin commented Nov 14, 2022

CLA assistant check
All CLA requirements met.

@AaronRobinsonMSFT
Copy link
Member

/cc @lambdageek @vargaz

@vargaz
Copy link
Contributor

vargaz commented Nov 14, 2022

Looks ok to me.

Fixed 2nd parameter for argumentExceptions
@jkoritzinsky
Copy link
Member

Can we switch all of the string.Format calls to SR.Format?

@databunks
Copy link
Contributor Author

databunks commented Nov 15, 2022

Can we switch all of the string.Format calls to SR.Format?

@jkoritzinsky

Is this just in the path:
/src/mono/System.Private.CoreLib ??

@jkoritzinsky
Copy link
Member

Yeah only within your change.

string.format -> SR.Format
jkotas
jkotas previously requested changes Nov 20, 2022
Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems to be a lot of opportunities in de-duplicating the new error strings with the existing error strings. I have commented on some, but there is certainly more.

The easy way to do the deduplication is to build a small program that hits the error path, run it on CoreCLR and see what error it produces in that case.

@ghost ghost added the needs-author-action An issue or pull request that requires more info or actions from the author. label Nov 20, 2022
@ghost ghost removed the needs-author-action An issue or pull request that requires more info or actions from the author. label Nov 21, 2022
@databunks
Copy link
Contributor Author

databunks commented Nov 21, 2022

There seems to be a lot of opportunities in de-duplicating the new error strings with the existing error strings. I have commented on some, but there is certainly more.

The easy way to do the deduplication is to build a small program that hits the error path, run it on CoreCLR and see what error it produces in that case.

@jkotas

Would a way to do it be like:

have a script which iterates through all of the exception strings in the .resx file
e.g: Arg_Enc (inside resx) -> find SR.Arg_Enc in the path ./src/mono/System.Private.CoreLib

If true dont remove, else remove??

and ill make a backup just in case

then run the build see if theres any missing references

@jkotas
Copy link
Member

jkotas commented Nov 21, 2022

have a script which iterates through all of the exception strings in the .resx file

I do not think you can script it. The error messages are not exactly the same. You need to be looking for same meaning that can be only done by humans (or AI).

@databunks databunks requested review from jkotas and removed request for marek-safar November 23, 2022 19:02
@databunks
Copy link
Contributor Author

have a script which iterates through all of the exception strings in the .resx file

I do not think you can script it. The error messages are not exactly the same. You need to be looking for same meaning that can be only done by humans (or AI).

ok thanks ill look into it
(also didnt mean to re-request review sorry)

@danmoseley
Copy link
Member

danmoseley commented Mar 20, 2023

Not related to this change, but I see some ApplicationException and base Exception getting thrown, which we generally don't throw, does CLR throw the same in these cases?
(Don't change this PR for that, just curious)

@akoeplinger
Copy link
Member

I see some ApplicationException and base Exception getting thrown, which we generally don't throw, does CLR throw the same in these cases?

No, we should clean those up at some point. You'd expect the same exception being thrown, regardless of runtime implementation.

@akoeplinger
Copy link
Member

Regarding the CLA, it looks like some issue with the new CLA system since it was signed in the old system according to #78341 (comment) and the status on one of the earlier commits:
image

I'll try to find someone who can look into that.

akoeplinger and others added 2 commits March 20, 2023 21:08
Co-authored-by: Dan Moseley <danmose@microsoft.com>
Co-authored-by: Dan Moseley <danmose@microsoft.com>
@akoeplinger
Copy link
Member

akoeplinger commented Mar 21, 2023

@databunks this is ready now, would you mind signing the CLA again? You signed right when we were transitioning to a new CLA system and looks like yours got missed.

You can do so by commenting @dotnet-policy-service agree here.

Edit: we were able to update the new system instead so this is handled now.

# Conflicts:
#	src/mono/System.Private.CoreLib/src/Mono/RuntimeMarshal.cs
@@ -24,7 +24,7 @@ public static FieldInfo GetFieldFromHandle(RuntimeFieldHandle handle, RuntimeTyp
throw new ArgumentException(SR.Argument_InvalidHandle);
FieldInfo fi = internal_from_handle_type(handle.Value, declaringType.Value);
if (fi == null)
throw new ArgumentException("The field handle and the type handle are incompatible.");
throw new ArgumentException(SR.Argument_FieldPropertyEventAndTypeHandleIncompatibility);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be Argument_ResolveFieldHandle like in CoreCLR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically yes but I don't have the type(s) to fill in the format string and RuntimeFieldHandle.GetApproxDeclaringType is only implemented in CoreCLR.

I'd rather keep this as is for now so we can finally get this PR in.

@akoeplinger akoeplinger changed the title Replacing exception strings with those stored in the resx file (#34056) Mono: Replace exception strings with those stored in the resx file (#34056) Mar 23, 2023
@akoeplinger akoeplinger merged commit 830d3d0 into dotnet:main Mar 23, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Apr 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Replace strings with resources in Mono corelib
8 participants