Error Code

Jul 6, 2009 at 4:54 PM

Will be a nice feature to put an "Error Code" in along with fieldName and Error Message.

Coordinator
Jul 7, 2009 at 9:43 AM

Hi!

Thanks for the suggestion. Do you mean adding an error code to each validation rule, something like:

Validate.That(Name, "Name").IsLongerThan(3, "Your name is too short.", 42).IsShorterThan(100, "Your name is too long.", 101);

Where 42 and 101 are the error codes? And then ValidatorResult will contain this code too? Are you seeing it as a numeric code (something we could put in an int)? Guess we'd have to figure out a sane behavior if there was no error code set and you tried to get one from ValidatorResult. And also it's yet another overload on every rule (wish they hadn't taken until C# 4 to do optional parameters...), but we can cope with that.

Thanks,

Jonathan



 

Jul 7, 2009 at 12:18 PM

That's it Jonathan.

I think that this code should be like Http Error Codes, and every pre defined validation has its own error code already like the message and can be overrided.

Coordinator
Jul 21, 2009 at 2:03 PM

Sorry for slow reply...been taking some vacation. :-)

I agree string values are far too fragile for determining what went wrong, rather than just having the strings to present to the user.

Maybe an enum is nicer than just numbers, but that makes it harder to specify your own error code. Unless we make the errors enum some generic type parameter...but that could get ugly and confusing.

Even crazier, I also wondered if we can do it with method handles or something.

 

if (Error.What == StringValidator.IsRegex)
    ....;

 

Didn't play with that idea yet, but it may be nice in that we don't have to introduce another bunch of enumerations mapping to something that's already there. But again, blows away your ability to supply a custom error code of some kind.

Well, more than one way to do it...I'm not leaning too strongly to any of them yet. Maybe Tore has some thoughts too...

Thanks,

Jonathan

Jul 21, 2009 at 2:29 PM

What I thinked was to have an simple number code only. I think that we don't need to make something too complex here. We could treat this code just like treat the messages.

And even better, the xml with the messages could be indexed with that codes.

Jul 27, 2009 at 9:21 PM

I've made an implementation for the Error Code and submit an patch.

What I do to prevent another overload for each validation method is to define an code before the validation, just like an Not.

If no code is defined it will get the default code for the method.

Coordinator
Jul 28, 2009 at 5:18 PM

Thanks for the patch!

I have already applied the Portuguese Language part of it and committed it today to the SVN repository. So that will be in the next release. Great to have. I renamed the file to have .por rather than .bra since we're going on the ISO-639 language name codes (see http://www.loc.gov/standards/iso639-2/php/English_list.php for details) which lists the code por for Portuguese.

The error codes part I want to review a bit more, plus Tore (the other project admin) will want to take a look at that too. When we add a feature like this, we need to think about maintaining it into the future and so forth - it's a fairly big addition. So I will get back to you on that part in a bit, once we've had chance to look through it and consider it a bit more.

Thanks again,

Jonathan

Jul 28, 2009 at 6:03 PM

Jonathan,

the language part I used bra because exists portuguese from Brazil and from Portugal, and they are very different. I take a look at the list and this list only consider the Portugal one. Maybe its the case to use another pattern like pt-br, en-us etc...

Coordinator
Jul 29, 2009 at 10:58 AM

Oh, hmm, you're completely right that we should differentiate the different Portugueses. And as you notice, ISO-639 does not do so. OK, so, we should switch to a different scheme. Thanks for the feedback.

In other news, I've applied the error codes part of your patch now. I re-worked the way it set the error code (just pass it to an overloaded version of SetResult rather than a protected SetErrorCode method, since protected methods don't play nice with adding rules through use of extension methods, which we've documented as a way to extend stuff). But other than that, the rest is pretty much as you supplied it. So thanks! :-)

The one thing your patch was missing was some unit tests for the new functionality. If you're up for writing some, let me know, otherwise I'll get to it sometime soonish.

Thanks again,

Jonathan

Coordinator
Jul 29, 2009 at 11:11 AM

Switched us to using ITEF tags now, and renamed various files to match. So we now have pt-BR for the one you submitted. :-)

Thanks,

Jonathan

Coordinator
Jul 30, 2009 at 4:16 PM

Tests for error codes stuff committed today and a few more tweaks.

Thanks,

Jonathan