integer validation

[Eugene Anthony]

How do I validate an integer number using asp.net with c#?

Eugene Anthony

 

[Eliyahu Goldin]

You can:

1) call Int32.Parse method and catch exceptions
2) call Int32.TryParse method and check the return value
3) don't validate anything, just go ahead. You will get an exception if
something is wrong.

3) is the common choice in most of scenarios.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

 

[Rad [Visual C# MVP]]

You can:

1) call Int32.Parse method and catch exceptions
2) call Int32.TryParse method and check the return value
3) don't validate anything, just go ahead. You will get an exception if
something is wrong.

3) is the common choice in most of scenarios.

Or better yet you could use a ASP.NET data type check validator

 

[Eliyahu Goldin]

Some developers consider validators cumbersome and don't use them.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

 

[Mark Rae]

Some developers consider validators cumbersome and don't use them.

I certainly never use them - my library of client-side JavaScript validation
routines is many times more flexible...

 

[Rad [Visual C# MVP]]

Some developers consider validators cumbersome and don't use them.

Hmm ... Cumbersome? How so? Personally I find them to be pretty handy. Drag
onto the page, set a few properties and you're good to go. Though one
should do sever side validation anyway just in case javascript has been
disabled on the client

 

[sloan]

Mark

Looks like another "rapid vs good" kind of debate.


The custom validators are good for rapid development.

But I (as it seems Mark) has done, is created some custom and reusable java
scripts routines.

The biz layer should check and catch for all errors. The use of JavaScript
should only be used to avoid a round trip to the server.
Why?

What if you want to code up a winforms presentation layer? You'd have to
re-code up all those checks if you didn't put them properly in the biz
layer.
Aka, now 2 places to upkeep and maintain. And one of them (javascript)
isn't even guaranteed to work.

Do your checks in the biz layer. Create some custom exceptions.
Use javascript as a helper to avoid a round trip.

You'll also notice that the custom validators are only the most trivial
things.

When you start working with forms with complicated rules beyond stuff like
"yes / no" or some text in a textbox, then having some better than the
custom validators makes your code better and more maintainable.

I'm sure others will disagree. I've worked with some of you in the past and
present.

...

 

[Mark Rae]

Looks like another "rapid vs good" kind of debate.

Yes indeed.

The custom validators are good for rapid development.

Only if you never intend to do anything even slightly complex with them...

But I (as it seems Mark) has done, is created some custom and reusable
java
scripts routines.

Indeed. In fact, armed with a comprehensive JavaScript validation library,
it is in fact much easier (and therefore quicker) *not* to use the custom
validators!

Same argument for the new SqlDataSource / ObjectDataSource stuff - if you
have a decent DAL, it's much easier not to use them...

You'll also notice that the custom validators are only the most trivial
things.

That is my main reason for not using them...

When you start working with forms with complicated rules beyond stuff like
"yes / no" or some text in a textbox, then having some better than the
custom validators makes your code better and more maintainable.

I couldn't agree more.