Exception Handling - Good Practice

  • Thread starter Thread starter CJM
  • Start date Start date
C

CJM

I'm working on my first real VB.NET application; I come from a VB6/ASP
background, so obviously a lot of my previous best practice is obsolete.

I'm creating a simple app that will email customers in our database with a
standard mailshot. I'm wanting to handle situations where the user enters an
invalid (i.e. amlformed) email address; I can think of a dozen ways that I
could do it but I'd rather prefer to hear what people think is good
practice. I have some code that checks if the email is well-formed but it's
more a question of where and when to use it.

For example, I could:

- Raise an Exception in the Property Set code
- Check the email address in the main method for the mailing class, and
raise an Exception - ie. check immediately prior to sending the email.
- Not bother checking for well-formedness - just catch the Exception from
the System.Net.Mail components
- Plan D?

Much of what I have read encourages me to use Try/Catch/Finally, yet some
people reckon Exceptions are a lazy way to handle anticipated problems...
Any comments?

Another thing that struck me is the lack of an error number as such. For
example, isn't there a need to discriminate between different instances of
the same type of Exception? We could have two ArgumentExceptions that we
want to handle differently... Am I to assume that this is where custom
Exceptions are in order?

It also seems unusual that some much - and yet so little - information is
provided by the Exception. You get a message but not much else that is of
use (as far as this noob can see). For example, if I allow the
System.Net.Mail.MailMessage object to handle a malformed email address, I
get the following message "The specified string is not in the form required
for an e-mail address.". Obviously in testing I know when email address
(From/To/CC/BCC) is malformed, but how can I tell at runtime. I'm sure I
must be missing 'something' - I realise the journey from COM to .NET is
completed overnight.

Thanks in advance...

CJM
 
I'm working on my first real VB.NET application; I come from a VB6/ASP
background, so obviously a lot of my previous best practice is obsolete.

I'm creating a simple app that will email customers in our database with a
standard mailshot. I'm wanting to handle situations where the user enters an
invalid (i.e. amlformed) email address; I can think of a dozen ways that I
could do it but I'd rather prefer to hear what people think is good
practice. I have some code that checks if the email is well-formed but it's
more a question of where and when to use it.

For example, I could:

- Raise an Exception in the Property Set code
- Check the email address in the main method for the mailing class, and
raise an Exception - ie. check immediately prior to sending the email.
- Not bother checking for well-formedness - just catch the Exception from
the System.Net.Mail components
- Plan D?

Much of what I have read encourages me to use Try/Catch/Finally, yet some
people reckon Exceptions are a lazy way to handle anticipated problems...
Any comments?

Another thing that struck me is the lack of an error number as such. For
example, isn't there a need to discriminate between different instances of
the same type of Exception? We could have two ArgumentExceptions that we
want to handle differently... Am I to assume that this is where custom
Exceptions are in order?

It also seems unusual that some much - and yet so little - information is
provided by the Exception. You get a message but not much else that is of
use (as far as this noob can see). For example, if I allow the
System.Net.Mail.MailMessage object to handle a malformed email address, I
get the following message "The specified string is not in the form required
for an e-mail address.". Obviously in testing I know when email address
(From/To/CC/BCC) is malformed, but how can I tell at runtime. I'm sure I
must be missing 'something' - I realise the journey from COM to .NET is
completed overnight.

Thanks in advance...

CJM
Click to expand...

Don't use exceptions. They have a massive memory overhead and they are
for lazy programmers. You should perform your own email checking using
code either on the form where you prompt for the information or, if
it's a dumb, model-view-controller situation, on the form / module
that opens the form for the input.

An Exception itself is an object, therefore you can catch different
subclasses, or even make your own like this:

Public Class MyDriverLostNetworkConnection
Inherits Exceptions

public mConnName as String

End Class

and throw it like this:

dim n as new MyDriverLostNetworkConnection()
n.mConnName = "Master Server 1"
throw n

and catch it like this:

try
'do something
catch e1 as MyDriverLostNetworkConnect
'messagebox.show("sorry user, somethings happened")
catch e2 as InvalidOperationException
'sorry user, something went wrong
catch e3 as Exception
'Any exception could of happened here!
end try

--

But seriously, it's just lazy to throw and catch exceptions when it's
just bad user input. In fact it's not just lazy, it actually
demonstrates incompetence on the part of the developer, who clearly
cannot write clean code. I mean, if the property set code detects an
exception...it WILL need to throw an exception because it's not part
of the UI code (I imagine) but if the developer doesn't test and clean
his input first then he is basically saying "let me put my logic,
specifically, in the wrong place and escape this bad path of logic
later". It's the wrong place because you can't notify the user at that
point...hense the need to throw it up the call stack. You should
handle errors at the places they can happen and not rely on someone's
clean code to indicate your application is incapable of testing an
email address. If your at the top level UI code when your about set
the property, it's the perfect time to check it, because you can still
tell the user that it's wrong. And why waste memory and time caused by
the overhead of throwing and catching an exception on purpose? If you
find it easier somehow then your bad programmer and I don't understand
how anyone can argue otherwise. Exceptions were designed are dealing
with problems you cannot avoid, like a network failure during a client-
server conversation, or a disk failure during a load or save.

Anyway that's my opinion.

Phillip Ross Taylor
 
Don't use exceptions. They have a massive memory overhead and they are
for lazy programmers. You should perform your own email checking using
code either on the form where you prompt for the information or, if
it's a dumb, model-view-controller situation, on the form / module
that opens the form for the input.

An Exception itself is an object, therefore you can catch different
subclasses, or even make your own like this:

Public Class MyDriverLostNetworkConnection
Inherits Exceptions

public mConnName as String

End Class

and throw it like this:

dim n as new MyDriverLostNetworkConnection()
n.mConnName = "Master Server 1"
throw n

and catch it like this:

try
'do something
catch e1 as MyDriverLostNetworkConnect
'messagebox.show("sorry user, somethings happened")
catch e2 as InvalidOperationException
'sorry user, something went wrong
catch e3 as Exception
'Any exception could of happened here!
end try

--

But seriously, it's just lazy to throw and catch exceptions when it's
just bad user input. In fact it's not just lazy, it actually
demonstrates incompetence on the part of the developer, who clearly
cannot write clean code. I mean, if the property set code detects an
exception...it WILL need to throw an exception because it's not part
of the UI code (I imagine) but if the developer doesn't test and clean
his input first then he is basically saying "let me put my logic,
specifically, in the wrong place and escape this bad path of logic
later". It's the wrong place because you can't notify the user at that
point...hense the need to throw it up the call stack. You should
handle errors at the places they can happen and not rely on someone's
clean code to indicate your application is incapable of testing an
email address. If your at the top level UI code when your about set
the property, it's the perfect time to check it, because you can still
tell the user that it's wrong. And why waste memory and time caused by
the overhead of throwing and catching an exception on purpose? If you
find it easier somehow then your bad programmer and I don't understand
how anyone can argue otherwise. Exceptions were designed are dealing
with problems you cannot avoid, like a network failure during a client-
server conversation, or a disk failure during a load or save.

Anyway that's my opinion.

Phillip Ross Taylor
Click to expand...

let me rephase this line:

"You should handle errors at the places they can happen"

to this:

"You should handle errors at the places you can DEAL WITH THEM"

For example, you have to throw an exception up from the property set
because you cannot interact with the user to ask for a new version,
and you cannot skip the step and jump on to the next part of the
process because you don't know what it is. Your just a property set
piece of code. You cannot make that decision. The code at the higher
level, can however, decide if the input is valid and if not, ask the
user to correct it. Or, it could ignore the input and not set the
property instead moving directly on to the next step. The code that
asks for the email can probably determine how important it is and what
constitutes a valid email. The property set, I assume, cannot make
that judgement call, hence it's need to throw an exception.

Phillip Taylor B.Sc. Hons
 
Raising the exception is not the real issue in my opinion. You need to
answer whether your user will:

1) need to fix the address as they enter it
2) just get a list of failed sends
3) have to fix each as they are sent

Exceptions themselves are fine. The important thing is to use them to help
the user fix in a smart way, what has gone amiss.
 
CJM,

I use only exceptions where I cannot do it with other code. By instance:

You can use exception to check if the mailserver fails.
You can use Regex to check if the mailAddress fails.

There are a bunch of Regex samples for Email url validation on internet, I
don't have one by hand now.

Cor
 
Thanks for the answers guys.

It's worth pointing out that in this particular scenario, the application is
reading email addresses from a DB so there is no opportunity for interaction
with a user. I'm just going to ignore an address if it isn't valid. I do
have some Regex code to parse email addresses, so I'm going to handle it
in-code; if the email is malformed, I'll tell it to just move on to the next
one...

CJM
 
Thanks for the answers guys.

It's worth pointing out that in this particular scenario, the application is
reading email addresses from a DB so there is no opportunity for interaction
with a user. I'm just going to ignore an address if it isn't valid. I do
have some Regex code to parse email addresses, so I'm going to handle it
in-code; if the email is malformed, I'll tell it to just move on to the next
one...

CJM
Click to expand...

My opinion would then be to wrap the Regex checks in a seperate bool
function. Then after pulling the possible addresses from the DB you
could use a very simple if...then block to filter the addresses.

Thanks,

Seth Rowe
 
CJM,

I use only exceptions where I cannot do it with other code. By instance:

You can use exception to check if the mailserver fails.
You can use Regex to check if the mailAddress fails.

There are a bunch of Regex samples for Email url validation on internet, I
don't have one by hand now.

Cor
 
Obviously, it's very early days for me when it comes to .NET, but I've
already created a Library project with a series of classes offering commonly
used functions; and IsValidEmail() was the first.
 
CJM said:
I'm creating a simple app that will email customers in our database with a
standard mailshot. I'm wanting to handle situations where the user enters an
invalid (i.e. amlformed) email address;
Click to expand...
For example, I could:

- Raise an Exception in the Property Set code
Click to expand...
Good, clean approach, assuming you have an object that represents an
individual mail message. It prevents you from sending a message to
anything that doesn't *look* like an email address, but it probably
won't spot a valid-looking address that simply doesn't /exist/, like
"(e-mail address removed)".
- Check the email address in the main method for the mailing class, and
raise an Exception - ie. check immediately prior to sending the email.
Click to expand...
Not so good. What you're describing here is Defensive Programming and
obviates much of the need for Exceptions. The program is effectively
saying to itself:
"Do I have valid email address, here?"
"No?"
"Then I can't send this, so I'll /do something different/".
That's just program logic.
- Not bother checking for well-formedness - just catch the Exception from
the System.Net.Mail components
Click to expand...
Assuming that you /get/ one! Some mail systems will take any old trash,
farm it out into their forwarding machinery and only when something,
four or five steps away, finally realises that it's been fed rubbish
does your message get bounced back - by which time your program's all
finished and killed itself off.
- Plan D?
Click to expand...
And the rest... ;-)
Much of what I have read encourages me to use Try/Catch/Finally, yet some
people reckon Exceptions are a lazy way to handle anticipated problems...
Click to expand...
Exceptions /should/ be show-stoppers. Just having a dodgy-looking email
address is something your code should deal with. Launching it towards
"Planet Email" and getting an Exception back that says "No; this really
/can't/ go" is something you "don't expect", and that's where Exceptions
come in.

Some people describe them as a way to deal with the things you don't
think of when writing the program, which is why so many people just have
one, global Exception Handler. Mind you, all it can do is to log the
error somewhere just before the application curls up its toes and dies.
IMHO, not a fat lot of good.
Others go as far as having Try .. Catch blocks in /every/ routine they
ever write. OK, there's very little overhead in doing this in normal
program operation; it's only when an Exception get /thrown/ that it all
springs into life (and boy! will you notice the hit the first time it
does).

My tuppence worth: If you can *usefully* catch an Exception - that is,
catch it, do something positive with it and then tell whatever routine
called this one that the error /didn't/ happen, then put a Catch in.
If you can't do anything useful at that point, then don't catch anything
(except, maybe, a comment about /why/ you're not catching the Exception
at this point).
Another thing that struck me is the lack of an error number as such. For
example, isn't there a need to discriminate between different instances of
the same type of Exception?
Click to expand...

Not that I can think of.
We could have two ArgumentExceptions that we want to handle differently...
Click to expand...

Why? ArgumentExceptions /tend/ to be thrown when you pass a method or
property set routine a value that's rubbish. Does it matter which one
of fifteen arguments it was? Can your /program/ take that [custom]
exception, interrogate it to work out which argument had the dodgy
value, go and get a /valid/ value for that argument and then "try
again"? If not, then there's nothing to be gained from knowing which
argument was wrong.
Am I to assume that this is where custom Exceptions are in order?
Click to expand...

Could be, but you'll wind up with lots and /lots/ of them.
It also seems unusual that some much - and yet so little - information is
provided by the Exception. You get a message but not much else that is of
use (as far as this noob can see). For example, if I allow the
System.Net.Mail.MailMessage object to handle a malformed email address, I
get the following message "The specified string is not in the form required
for an e-mail address.".
Click to expand...

The Exception you get handed /ought/ to offer you additional properties
that indicate which address is at fault (but I'd wager that one doesn't).

HTH,
Phill W.
 
Don't use exceptions. They have a massive memory overhead and they are
for lazy programmers.
Click to expand...

Have you benchmarked the performance of exceptions? They aren't
nearly as costly as most think. While I certainly don't advocate
using them "willy-nilly" I think email validation is an acceptable
scenario. Have you seen the regular expression for validating an RFC
822 compliant email address? Catching an exception could be several
orders of magnitude more reading in this particular case. I haven't
benchmarked the regular expression approach versus catching an
exception so I can't comment with any credibility on that front other
than to say that it wouldn't surprise me if the difference were
insignificant.
 
Back
Top