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

Add MatchStringSafe Method to Simplify Error Handling in MatchString #84

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

KiddoV
Copy link

@KiddoV KiddoV commented Aug 8, 2024

Description

This PR introduces a new method MatchStringSafe to the Regexp struct. The new method simplifies the use of regular expressions by returning only a boolean value, ignoring any errors that might occur. This is particularly useful when users are not concerned with specific error handling (e.g., timeout errors) and prefer a simple true/false response.

While the existing MatchString method is robust and provides detailed error information, there are many cases where users may not need to handle errors explicitly. In these cases, the additional complexity of dealing with an error value can be cumbersome. The MatchStringSafe method simplifies this common use case by allowing users to write more concise and readable code when error handling is not required.

@dlclark
Copy link
Owner

dlclark commented Aug 8, 2024

An interesting idea. Is the “Safe” suffix a standard name for this kind of “throw away an error” method in Go? I think I’ve seen it before but can’t remember where. Any examples?

@ccoVeille
Copy link

"Safe" is not commonly used.

"Must" is a common suffix for using a panic on error. But it's not the need here.

IsMatchString could be a candidate, but it sounds strange to me.

ValidateString sounds better maybe.

While I understand the need, I'm bad at wording 😅

@ccoVeille
Copy link

Anyway, I'm unsure such method should be provided. Apparently, the only source of error is the timeout. But having a process that detects the presence of something that may say "ok not found" is dangerous as it could lead to taking wrong decision, such as deleting a file. Or something like that.

I mean if a user code such helper in their code, they are aware of what they do. But providing such helper in the lib could be dangerous

Many people are not aware there is a timeout mechanism in this lib.

@ccoVeille
Copy link

MustMatchString that would call MatchString and panic on error, otherwise return a boolean, might be a better and more logic

But having a random panic depending on the timeout is also strange.

@dlclark
Copy link
Owner

dlclark commented Aug 8, 2024

By default the timeout mechanism is off, so this could be converted to a "Must" style function that panics if a timeout happens. Lots of examples of Must-style floating around.

@ccoVeille
Copy link

Yes, that's why I suggested that

But to find a solution for author needs
Here is how samber/lo does

https://pkg.go.dev/github.com/samber/lo#Must

It's what was asked.

So Must seems to be good prefix

@dlclark
Copy link
Owner

dlclark commented Aug 8, 2024

(I think we're on the same page I posted my message before I saw yours)

Honestly this feels like a trivial wrapper that anybody could write in their code:

func Must[T any](v T, err error) T {
	if err != nil {
		panic(err)
	}
	return v
}

Does it really need to be in the regexp2 lib?

@ccoVeille
Copy link

Yes, that's what I stated here

#84 (comment)

@KiddoV
Copy link
Author

KiddoV commented Aug 8, 2024

Thanks for the feedback, everyone.
I understand the concerns about potentially introducing unsafe practices by ignoring errors, especially with the timeout mechanism. However, I believe the utility of a method like MatchStringSafe lies in its ability to simplify code for users who are confident that they don't need detailed error handling for their specific use case.

The method is not intended to replace the existing MatchString but to complement it for scenarios where simplicity and readability are prioritized over robust error handling. Developers who prefer more control over error handling can continue to use MatchString, while those who are aware of the trade-offs can benefit from a cleaner, more straightforward option.

Naming-wise, while MustMatchString might be a common Go convention, it typically implies a panic on error, which is different from the intent here. If the "Safe" suffix isn't ideal, perhaps TryMatchString could be an alternative, indicating that it attempts the match but without the complexity of error management.

Ultimately, adding this method would provide more flexibility to the library's users, giving them the choice to balance simplicity and safety as needed.

The method name inspired by this lib: https://github.com/gookit/goutil

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants