This is in response to the comments and blog posts made on Jeffrey Schoolcraft's and Darren Neimke's blogs.

I have to disagree with the blanket statement that regular expressions should never, ever be used to try and match email, date, or HTML patterns.  I'm almost at a loss here to even get into it, because the first thing that comes to mind is to just say "Oh come on now, seriously!"  Granted the comment was left on April Fool's Day (although the server claims otherwise)... Anyway, in order to disprove the blanket statement, it is only necessary to come up with a single useful application for such expressions, preferably one for which a more code-intensive approach would not be well-suited.

How about data entry?  I've written a few call center applications.  It's also common these days to use web-based data entry applications on intranets because of the easy updates web-based applications allow for.  With any data entry application, speed of entry is important, but so is accuracy.  The best time to correct something is as soon as it's been entered (through input masking or perhaps OnBlur).  To accomplish this in a web application typically means JavaScript.  JavaScript supports regular expressions quite well, but isn't really well-suited to communicating with mail servers.

So, ideally, if you want the best user experience, you'll use a regular expression for the emails, dates, phone numbers, etc. in the application tied to javascript.  Then, when a record is submitted, you can perform better validation.  It might be sufficient just to check that the email was well-formed and the date properly formatted with the regex, while the application uses code to try to verify that the email is valid (or ideally, requires the user to confirm it by responding to an emailed inquiry).  The application would also be responsible for ensuring that dates, beyond being properly formatted, are valid for whatever purpose they're serving (date of birth probably should be in the past, for instance).

Thus, regular expressions can provide 'good enough' validation to allow for most typographic errors to be caught and enhance the user experience by providing immediate feedback in scenarios where code-intensive validation is impractical.  Better validation should then be performed elsewhere, usually in some middle tier business rule enforcing area.

This is the most obvious example, and one I've personally encountered many times as a consultant at different companies.  I'm sure there are other scenarios where the quickness and simplicity of a regex outweighs the value of the additional accuracy that a more code intensive approach might provide.  Again, it's a trade-off of what is 'good enough' and in many cases a regex will suffice even in situations where it doesn't catch every possible error.