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]

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.

 

[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?

 

[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.

 

[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

 

[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

 

[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.

 

[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]

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/d.../html/cpconerrorraisinghandlingguidelines.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.

 

[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

 

[Kevin Spencer]

You missed my point.

--
HTH,

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