TryParse for email addresses

[Grauenwolf]

Currently we have to write this code:

        public static bool IsEmailAddress(this string value)
        {
            try
            {
                new System.Net.Mail.MailAddress(value);
                return true;
            }
            catch ()
            {
                return false;
            }
        }

MailAddress should have a TryParse method like Int32.TryParse.

Rationale and Usage

Throwing and catching exceptions can have a significant impact on performance. So when possible there should be a non-throwing alternative for methods that commonly fail. An example would be Int32.Parse and Int32.TryParse.

There is also an impact on debugger. If you have the IDE set to "Break on All Exceptions" in order to see where an exception is being thrown, it will also catch this even though it is not interesting.

Proposed API

class MailAddress {
    public static MailAddress Parse(string address);
    public static MailAddress Parse(string address, string displayName);
    public static MailAddress Parse(string address, string displayName, Encoding displayNameEncoding);

    public static bool TryParse(string address, out MailAddress result);
    public static bool TryParse(string address, string displayName, out MailAddress result);
    public static bool TryParse(string address, string displayName, Encoding displayNameEncoding, out MailAddress result);
}

Details

Open Questions

[karelz]

Can you post full API proposal? (see API review process)

[Grauenwolf]

How's that look?

[karelz]

See the link I posted - it has details and also example. The key thing is that API should be thought through various points of views (usage patterns, similar patterns in BCL, etc.)

Ah, I didn't realize you updated top post.

[Grauenwolf]

My apologies, I see how my last comment was a bit ambiguous.

[euclid47]

@Grauenwolf Have you tried writing an extension class to accomplish this task?

[ctolkien]

Alternatively, why not make the MailAddressParser which the MailAddress uses under the covers not internal?

https://github.com/dotnet/corefx/blob/f0ccd9742065ee2aa296448fe3dd38ef6ff77af9/src/Common/src/System/Net/Mail/MailAddressParser.cs#L21

[Grauenwolf]

As long as it has a TryParse method, I have no preference.

[satano]

@euclid47
Own extension is not enough, because it will still have the issues @Grauenwolf mentioned in his rationale: impact on performance because of thrown exception and troubles in IDE when you use Break on All Exceptions. The other disadvantage of extension is, that you have to have an instance already and this should be static methods as shown in proposed API.

@ctolkien
This probably will not work so easily. My opinion is, that the implementation of TryParse should not throw any exceptions even internally because od performance (of course arguments checking and thus some Argument[Null]Exception is OK).

I agree with @Grauenwolf that TryParse would be a very nice method to have. We also use the try-catch block just to check if string is valid email.

[blowdart]

The only way to discover if an email is valid is to send an email to it and see what happens. Just because it looks like an email address does not mean it's valid. When you TryParse on a number the result indicates that the value parsed is, or is not, a number. TryParse for email addresses cannot do this.

As people make security decisions on email addresses I would not like to see this added.

(As an aside I wish System.Net.Mail would just go away).

[ctolkien]

We also use the try-catch block just to check if string is valid email.

My experience is that the only real way to check if an email is valid is to send an email to it.

Edit: gah beaten.

[Grauenwolf]

That's like arguing we shouldn't parse someone's date of birth because the only way to know if the DOB is valid is to check the birth certificate.

If using for UI validation, you shouldn't wait for a bounce to inform the user they typed "me#google.com".

Personally I'm not even using it for sending emails. I'm using it to extract the user and host name as separate fields for LDAP lookups. (Which also proves the email address is valid without sending an email.)

[Grauenwolf]

On another project I need to read the top 10,000 rows from each table and see which non-null columns always, never, or sometimes contain email addresses.

Again, I need an email address parser. But I'm not going to be actually sending out emails.

---

Finally, how would you use an email address alone for security? Even if you did send a validation email, it could be to a fake address set up for that purpose.

[WiredUK]

You were given an email parser in your Stack Overflow question, so what more do you need really? I'm in agreement with @blowdart here, not keen on adding extra APIs to parse email addresses, especially as the rules for what a valid address has the potential to change, meaning the API would go out of date.

[Grauenwolf]

I fail to see the logic in your argument. Class MailAddress isn't going away. In the unlikely event that the definition of an email address changes, it will have to be updated anyways.

And no, a Regex is not a substitute for a standards compliant parser.

[euclid47]

@Grauenwolf For both questions I would ask these on stackoverflow.com due to being off topic. Both questions are important and I have a few ideas to accomplish both tasks.