c#/aspx error handling

[suzy]

i am trying to write aspx login system and the login process requires a
validity check of username and password.

i have been told that raising exception is costly, but i want a custom error
message to be displayed depending on what error occurred (let's say: invalid
username, invalid password, password must contain 5 or more characters,
etc).

at the moment, my login method is returning true/false depending on whether
the login was succesful or not. however, if the login fails, how will my
calling function know what error occurred without raising an exception?

i know i could return numbers from the login method back to the calling
function (where each number represents a different error), but then i would
have to check the value of the number on every calling function that uses
the login method, and write the appropritate error messages on EVERY calling
function.

is there a way i can write my code so i only have to write the error in the
login function, and calling functions will pick up the error message if the
login fails?

thanks

[Jerry III]

If you want to go the easy way just return a string instead of a boolean
value. Null means success, anything else is the actual error message (or its
resource id if you want to localize). But it's not a good security practice
to show this info, it allows for a lot easier break-in (saying the password
is incorrect means you have a valid login name and now you just need the
password, giving out information on how long the password needs to be narrow
down the search space dramatically and so on). If you want to be safe just
show a generic "Invalid user name or password" message for failed logins.

Jerry

"suzy" <[e-mail]> wrote in message
news:eg**************@TK2MSFTNGP12.phx.gbl...

i am trying to write aspx login system and the login process requires a
validity check of username and password.

i have been told that raising exception is costly, but i want a custom error message to be displayed depending on what error occurred (let's say: invalid username, invalid password, password must contain 5 or more characters,
etc).

at the moment, my login method is returning true/false depending on whether the login was succesful or not. however, if the login fails, how will my
calling function know what error occurred without raising an exception?

i know i could return numbers from the login method back to the calling
function (where each number represents a different error), but then i would have to check the value of the number on every calling function that uses
the login method, and write the appropritate error messages on EVERY calling function.

is there a way i can write my code so i only have to write the error in the login function, and calling functions will pick up the error message if the login fails?

thanks

[suzy]

Yes I see what you're saying, but it's the theory I'm interested in. I just
used the login as an example.

What if I had a function that really did need to return the type of error
that occurred. I could return null on success and the error message on
failure, but what if the function was meant to return a dataset or
something? How would I retrieve an error in that scenario?

The only neat way I can think of doing it is to throw an exception, but
that's too costly by the sounds of things.
"Jerry III" <je******@hotmail.com> wrote in message
news:eq**************@TK2MSFTNGP09.phx.gbl...

If you want to go the easy way just return a string instead of a boolean
value. Null means success, anything else is the actual error message (or its resource id if you want to localize). But it's not a good security practice to show this info, it allows for a lot easier break-in (saying the password is incorrect means you have a valid login name and now you just need the
password, giving out information on how long the password needs to be narrow down the search space dramatically and so on). If you want to be safe just
show a generic "Invalid user name or password" message for failed logins.

Jerry

"suzy" <[e-mail]> wrote in message
news:eg**************@TK2MSFTNGP12.phx.gbl...

i am trying to write aspx login system and the login process requires a
validity check of username and password.

i have been told that raising exception is costly, but i want a custom

error

message to be displayed depending on what error occurred (let's say:

invalid

username, invalid password, password must contain 5 or more characters,
etc).

at the moment, my login method is returning true/false depending on

whether

the login was succesful or not. however, if the login fails, how will my calling function know what error occurred without raising an exception?

i know i could return numbers from the login method back to the calling
function (where each number represents a different error), but then i

would

have to check the value of the number on every calling function that uses the login method, and write the appropritate error messages on EVERY

calling

function.

is there a way i can write my code so i only have to write the error in

the

login function, and calling functions will pick up the error message if

the

login fails?

thanks

[Anders Borum]

Hello!

The only neat way I can think of doing it is to throw an exception, but
that's too costly by the sounds of things.

You could return use an enumeration value from the function. This would keep
things pretty typesafe and you could handle the return value pretty easily.
How about that?

An error is not necessarily an exception. If you can handle and anticipate
the error, it's generally not a good idea to throw an exception. Throwing
exceptions automatically forces the users of your API to wrap a
try/catch/finally block around each method.

Or am I wrong? :-)

--
venlig hilsen / with regards
anders borum
--

[suzy]

Do you mean return an enum that contains the possible errors?

This would work if the function fails, but what if my function was meant to
return a dataset, boolean, etc if it succeeds?

I know I could get around this by setting all my functions to return
objects, rather than explicit types, but surely there must be a better way
of raising errors up the call stack.

In VB I would simply call Err.Raise with the appropriate error message.
This would be raised to my calling function and it would check to see if the
Err.Number is > 0 and display the Err.Message accordingly.
"Anders Borum" <[e-mail]> wrote in message
news:Og**************@TK2MSFTNGP12.phx.gbl...

Hello!

The only neat way I can think of doing it is to throw an exception, but
that's too costly by the sounds of things.
You could return use an enumeration value from the function. This would

keep things pretty typesafe and you could handle the return value pretty easily. How about that?

An error is not necessarily an exception. If you can handle and anticipate
the error, it's generally not a good idea to throw an exception. Throwing
exceptions automatically forces the users of your API to wrap a
try/catch/finally block around each method.

Or am I wrong? :-)

--
venlig hilsen / with regards
anders borum
--

[Hans Kesting]

I think that there is no generic answer (apart from "it depends..").

If I remember correctly from previous threads, exceptions are only
"expensive" when actually thrown.

So, if you can handle "expected errorconditions" (like "username/password
combination not correct"), especially ones that could occur often, without
exceptions, please do.
If there is an exceptional situation, that should not occur at all ("a
needed file
is not where expected"), then there is no problem throwing exceptions.

The exception mechanism is created epsecially for situations where you
need to signal some error-condition, without limits to the regular output
of the function.
Hans Kesting

"suzy" <[e-mail]> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Do you mean return an enum that contains the possible errors?

This would work if the function fails, but what if my function was meant to return a dataset, boolean, etc if it succeeds?

I know I could get around this by setting all my functions to return
objects, rather than explicit types, but surely there must be a better way
of raising errors up the call stack.

In VB I would simply call Err.Raise with the appropriate error message.
This would be raised to my calling function and it would check to see if the Err.Number is > 0 and display the Err.Message accordingly.
"Anders Borum" <[e-mail]> wrote in message
news:Og**************@TK2MSFTNGP12.phx.gbl...

Hello!

The only neat way I can think of doing it is to throw an exception, but that's too costly by the sounds of things.

You could return use an enumeration value from the function. This would

keep

things pretty typesafe and you could handle the return value pretty

easily.

How about that?

An error is not necessarily an exception. If you can handle and anticipate the error, it's generally not a good idea to throw an exception. Throwing exceptions automatically forces the users of your API to wrap a
try/catch/finally block around each method.

Or am I wrong? :-)

--
venlig hilsen / with regards
anders borum
--

[Jerry III]

I agree, instead of trying to come up with complicated schemes on how to
handle errors it's just easier to throw exceptions. In most cases simplicity
and readability of the code is more precious then few [hundred] CPU cycles,
you can easily upgrade your server and it pays off once you have to go back
to the code or add more people to the project - if it's easier to understand
the logic it saves a lot of time. And people time is lot more expensive than
server hardware...

Jerry

"John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
news:13**************************@posting.google.c om...

Personally I would throw an exception. It's true they are *relatively*
expensive and you shouldn't routinely throw and catch exceptions in
loops (for example), but you're not going to get hundreds of failed
logins a second, are you??!

If you don't want to define try..catch blocks everywhere, define a
Application_Error() method in Global.asax.cs

Also, you could define a custom error page in web.config, ie
<customErrors defaultRedirect="SysErrorPage.aspx" mode="RemoteOnly" />

This gets called after Application_Error() i think. So I use the
method to record exception details in the database, then present the
user with a nice message in the custom error page.

Don't be frightened of using exceptions when something doesn't go to
plan. It's what they're there for.

ie. every time we call Response.Redirect() an 'silent' exception is
raised.

John

"suzy" <[e-mail]> wrote in message

news:<e9**************@TK2MSFTNGP12.phx.gbl>...

Yes I see what you're saying, but it's the theory I'm interested in. I just used the login as an example.

What if I had a function that really did need to return the type of error that occurred. I could return null on success and the error message on
failure, but what if the function was meant to return a dataset or
something? How would I retrieve an error in that scenario?

[Robbie Harris]

lots of comments on this, but first there's the need to differentiate
between an *exception* and an expected state condition in your application.
invalid usernames, passwords, and failed field validations are not
necessarily exceptions. if they're not (and i'd suggest in your case they
arent) then yes, they would be relatively expensive if they were handled as
such. where such states will frequently occur (like your login form) you
should deal with them within the body of your code. there's nothing wrong
returning a boolean - false allows the UI to display a generic
'username/password combination failed message', which - as already pointed
out in this thread - is good practise. if you, as the developer, really need
to know what went wrong, write a trace entry including the values the user
posted.

from the thread you presumably have a class calling a login class and want
to branch depending on a returned value from that class. but you probably
shouldnt branch other than a if boolean == IsAuthenticated() - keep the
logic and expected state failures encapsulated in your login class - which
should raise exceptions out to the consumers only when expections occur -
such as the authentication provider not being accessible. indeed there's a
case to be made for not even returning that since such exceptions can
provide security sensitive data that could make its way back to the UI -
i've worked on a number of projects where we returned only a boolen, no
excpetions, from the authentication class.

r.

"suzy" <[e-mail]> wrote in message
news:eg**************@TK2MSFTNGP12.phx.gbl...

i am trying to write aspx login system and the login process requires a
validity check of username and password.

i have been told that raising exception is costly, but i want a custom error message to be displayed depending on what error occurred (let's say: invalid username, invalid password, password must contain 5 or more characters,
etc).

at the moment, my login method is returning true/false depending on whether the login was succesful or not. however, if the login fails, how will my
calling function know what error occurred without raising an exception?

i know i could return numbers from the login method back to the calling
function (where each number represents a different error), but then i would have to check the value of the number on every calling function that uses
the login method, and write the appropritate error messages on EVERY calling function.

is there a way i can write my code so i only have to write the error in the login function, and calling functions will pick up the error message if the login fails?

thanks

[Jerry III]

Now we're down to just playing on words but one could argue that invalid
authentication is an exception in the process of logging in. It really
depends on your point of view, you could argue that running out of disk
space while writing a file is not an exception as you should check if you
have enough space before you write, much like you check for user name and
password before you create a login ticket.

As for Kevin's post - even if you write the most efficient code possible it
will stay vulnerable to DoS attacks. I think most of the time the balance
tips towards writing clean code, not fast code. You're going to have less
errors and your code is going to be a lot easier to maintain. In most cases
that's worth more than speed, look at Microsoft's download center,
theoretically it's incredibly inefficient in the way it works (read about it
in Microsoft's backstage articles) but that's more than outweighed by the
manageability of the code and the whole system.

Jerry

"Robbie Harris" <ro***********@hotmail.com> wrote in message
news:bh**********@sparta.btinternet.com...

lots of comments on this, but first there's the need to differentiate
between an *exception* and an expected state condition in your application. invalid usernames, passwords, and failed field validations are not
necessarily exceptions. if they're not (and i'd suggest in your case they
arent) then yes, they would be relatively expensive if they were handled as such. where such states will frequently occur (like your login form) you
should deal with them within the body of your code. there's nothing wrong
returning a boolean - false allows the UI to display a generic
'username/password combination failed message', which - as already pointed
out in this thread - is good practise. if you, as the developer, really need to know what went wrong, write a trace entry including the values the user
posted.

from the thread you presumably have a class calling a login class and want
to branch depending on a returned value from that class. but you probably
shouldnt branch other than a if boolean == IsAuthenticated() - keep the
logic and expected state failures encapsulated in your login class - which
should raise exceptions out to the consumers only when expections occur -
such as the authentication provider not being accessible. indeed there's a
case to be made for not even returning that since such exceptions can
provide security sensitive data that could make its way back to the UI -
i've worked on a number of projects where we returned only a boolen, no
excpetions, from the authentication class.

r.

"suzy" <[e-mail]> wrote in message
news:eg**************@TK2MSFTNGP12.phx.gbl...

i am trying to write aspx login system and the login process requires a
validity check of username and password.

i have been told that raising exception is costly, but i want a custom

error

message to be displayed depending on what error occurred (let's say:

invalid

username, invalid password, password must contain 5 or more characters,
etc).

at the moment, my login method is returning true/false depending on

whether

the login was succesful or not. however, if the login fails, how will my calling function know what error occurred without raising an exception?

i know i could return numbers from the login method back to the calling
function (where each number represents a different error), but then i

would

have to check the value of the number on every calling function that uses the login method, and write the appropritate error messages on EVERY

calling

function.

is there a way i can write my code so i only have to write the error in

the

login function, and calling functions will pick up the error message if

the

login fails?

thanks

[Robbie Harris]

oh i agree that knowing when to raise an exception and when not is a matter
of judgement, and in mine an invalid username, password or field validation
is not an exception condition. the best practises are here:

http://msdn.microsoft.com/library/de...guidelines.asp

key among them:

* All code paths that result in an exception should provide a method to
check for success without throwing an exception
* Do not use exceptions for normal or expected errors, or for normal flow of
control.
* Do not expose secure information in exception messages.
* Design classes so that in the normal course of use an exception will never
be thrown.

r.

"John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
news:13**************************@posting.google.c om...

Couldn't agree more - exceptions are there to cope with error
conditions, and to me a failed login is an error condition. They're
not simply about major / rare / critical failures of the application.
The response.redirect() example in the framework proves this.

Often, I use both strategies: check something should work, try it, and
if it doesn't raise an exception. That way if I forget to check I'm
still protected!

Exceptions usually aid readibility, security and robustness of code
(especially when you design them in from the beginning). For me thats
the main factor.
<snip>
John

"Jerry III" <je******@hotmail.com> wrote in message

news:<uB**************@TK2MSFTNGP09.phx.gbl>...

Now we're down to just playing on words but one could argue that invalid
authentication is an exception in the process of logging in. It really
depends on your point of view, you could argue that running out of disk
space while writing a file is not an exception as you should check if you have enough space before you write, much like you check for user name and password before you create a login ticket.

[Jerry III]

Yet Microsoft themselves break three of these four quoted rules with
Response.Redirect. You have to realize that these rules are suggestions, not
dogmas. And there are going to be cases when it's better to code against
Microsoft's recommendations.

Jerry

"Robbie Harris" <ro***********@hotmail.com> wrote in message
news:bh**********@sparta.btinternet.com...

oh i agree that knowing when to raise an exception and when not is a matter of judgement, and in mine an invalid username, password or field validation is not an exception condition. the best practises are here:

http://msdn.microsoft.com/library/de...guidelines.asp
key among them:

* All code paths that result in an exception should provide a method to
check for success without throwing an exception
* Do not use exceptions for normal or expected errors, or for normal flow of control.
* Do not expose secure information in exception messages.
* Design classes so that in the normal course of use an exception will never be thrown.

r.

"John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
news:13**************************@posting.google.c om...

Couldn't agree more - exceptions are there to cope with error
conditions, and to me a failed login is an error condition. They're
not simply about major / rare / critical failures of the application.
The response.redirect() example in the framework proves this.

Often, I use both strategies: check something should work, try it, and
if it doesn't raise an exception. That way if I forget to check I'm
still protected!

Exceptions usually aid readibility, security and robustness of code
(especially when you design them in from the beginning). For me thats
the main factor.

<snip>

John

"Jerry III" <je******@hotmail.com> wrote in message

news:<uB**************@TK2MSFTNGP09.phx.gbl>...

Now we're down to just playing on words but one could argue that invalid authentication is an exception in the process of logging in. It really
depends on your point of view, you could argue that running out of disk space while writing a file is not an exception as you should check if you have enough space before you write, much like you check for user name and password before you create a login ticket.

[Kevin Spencer]

You missed my point.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Neither a follower nor a lender be.

"Jerry III" <je******@hotmail.com> wrote in message
news:uv**************@tk2msftngp13.phx.gbl...

Don't have to tell me that. The same can be said for the login class,
whatever implements the login process should throw exceptions if there's an error processing the login and the application using it should catch it.
Even though there's not a clear line between the application and the
authentication business logic. In the end it's a lot easier to use code that throws exceptions in case of an invalid user name or password than one that returns an error value (you'll eventually end up returning something similar to Exception class object anyways).

Jerry

"Kevin Spencer" <ke***@takempis.com> wrote in message
news:eo**************@tk2msftngp13.phx.gbl...

Actually, when designing a set of classes for use in developing programs
(such as the CLR), throwing exceptions is something those classes SHOULD

do.

The developer that uses these classes in an application should ensure that

the _application_ doesn't throw exceptions, by handling them.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
http://www.takempis.com
Neither a follower nor a lender be.

"Jerry III" <je******@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Yet Microsoft themselves break three of these four quoted rules with
Response.Redirect. You have to realize that these rules are suggestions,

not

dogmas. And there are going to be cases when it's better to code

against Microsoft's recommendations.

Jerry

"Robbie Harris" <ro***********@hotmail.com> wrote in message
news:bh**********@sparta.btinternet.com...
> oh i agree that knowing when to raise an exception and when not is a
matter
> of judgement, and in mine an invalid username, password or field
validation
> is not an exception condition. the best practises are here:
>
>

http://msdn.microsoft.com/library/de...guidelines.asp

>
> key among them:
>
> * All code paths that result in an exception should provide a method to > check for success without throwing an exception
> * Do not use exceptions for normal or expected errors, or for normal

flow

of
> control.
> * Do not expose secure information in exception messages.
> * Design classes so that in the normal course of use an exception will never
> be thrown.
>
> r.
>
> "John Sparrow" <js******@ecclescollege.ac.uk> wrote in message
> news:13**************************@posting.google.c om...
> > Couldn't agree more - exceptions are there to cope with error
> > conditions, and to me a failed login is an error condition. They're > > not simply about major / rare / critical failures of the application. > > The response.redirect() example in the framework proves this.
> >
> > Often, I use both strategies: check something should work, try it, and > > if it doesn't raise an exception. That way if I forget to check I'm > > still protected!
> >
> > Exceptions usually aid readibility, security and robustness of code > > (especially when you design them in from the beginning). For me thats > > the main factor.
> >
> <snip>
>
> > John
> >
> > "Jerry III" <je******@hotmail.com> wrote in message
> news:<uB**************@TK2MSFTNGP09.phx.gbl>...
> > > Now we're down to just playing on words but one could argue that
invalid
> > > authentication is an exception in the process of logging in. It

really

> > > depends on your point of view, you could argue that running out of disk
> > > space while writing a file is not an exception as you should

check if

> you
> > > have enough space before you write, much like you check for user

name

> and
> > > password before you create a login ticket.
>
>