Looking for advice on this rethrow of exception

[cmay]

I'm just looking for some other opinions on this.

I have a control that does employee lookups, auto complete of the name
etc.

Let say that this control is:
Company.Control s.Web.LookupCon trols.EmployeeL ookupControl

Now I have a Employee class:
Company.Busines s.Employee

The employee class takes an employee ID as one of its constructors, so
if you pass it an ID number for an employee that doesn't exist (for
example -1 or 100000000), it throws an exception:
Company.Busines s.EmployeeNotFo undException

Now my dilema is what to do when my application passes an invalid ID
number to my control EmployeeLookupC ontrol. The lookup control catches
the EmployeeNotFoun dException.

One part of me thinks that it should simply rethrown the
EmployeeNotFoun dException, and part of me thinks it should thrown it's
OWN exception so that consumers of the LookupControl would only have to
expect exceptions that belong to it, not other DLLs/namespaces. So
then I started thinking, what would I name the new exception if I did
choose to throw an exception? It seems like EmployeeNotFoun dException
properly describes the problem, but I am not sure having 2 exceptions
with the same name is a good idea, even if they are in different
namespaces.

So to boil it down.
Option 1: Rethrow the Company.Busines s.EmployeeNotFo undException
exception. Then applications would have to have a reference to the
DLL that holds that exception class, and developers would have to deal
with exceptions from other DLLs than the one they are dealing with when
setting the ID value of the employee.

Option 2: Make an exception class within the LookupControls DLL and
throw this exception.
Sub Option 2a: Use the same name EmployeeNotFoun dException. It's
ok b/c its in a different namespace.
Sub Option 2b: Make up a different name for the exception b/c it's
not good practice to have 2 exceptions with the same name, even if they
are in different namespaces.

[Tim Haughton]

"cmay" <cm**@walshgrou p.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

I have a control that does employee lookups, auto complete of the name
etc.
The employee class takes an employee ID as one of its constructors, so
if you pass it an ID number for an employee that doesn't exist (for
example -1 or 100000000), it throws an exception:
Company.Busines s.EmployeeNotFo undException
As a general rule, it's simply not cricket (excuse analogy - we've just won
the ashes) to have constructors throw exceptions. A better idea would be a
static factory method called FromID or something similar.
Now my dilema is what to do when my application passes an invalid ID
number to my control EmployeeLookupC ontrol. The lookup control catches
the EmployeeNotFoun dException.

Why not throw an ArgumentExcepti on and pass in the EmployeeNotFoun dException
as the inner exception?

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Mattia Adami]

I would choose option 1... But I'm not an expert programmer...
Why deal with exception from other dll is a problem?

[Helge Jensen]

cmay wrote:

So to boil it down.
Option 1: Rethrow the Company.Busines s.EmployeeNotFo undException
exception. Then applications would have to have a reference to the
DLL that holds that exception class, and developers would have to deal
with exceptions from other DLLs than the one they are dealing with when
setting the ID value of the employee.
I would let the exception out through, afterall the caller is much more
likely to have some code specific code to be run for not-found-employees
than for some ArgumentExcepti on or what-not.

The applications would *only* need to have a reference to the DLL with
the exception if they wish to use it as an EmployeeNotFoun dException,
they can catch it as Exception, and log it or whatnot, just fine.

You keep saying "rethrow", why are you even catching the exception?
Option 2: Make an exception class within the LookupControls DLL and
throw this exception.
You are going to have to write a lot of these wrappers, and no matter
how many you write, you can never be certain that the code you call will
not throw one you haven't wrapped.

The alternative is to have a SomethingWentWr ongInMyModuleEx ception, and
attach the original Exception to the .Inner of that. But this requires
anyone who wish to catch only EmployeeNotFoun dException to catch
SomethingWentWr ongInMyModuleEx ception and inspect it's .Inner, not very
nice at all.
Sub Option 2a: Use the same name EmployeeNotFoun dException. It's
ok b/c its in a different namespace.
Sub Option 2b: Make up a different name for the exception b/c it's
not good practice to have 2 exceptions with the same name, even if they
are in different namespaces.

The name is not really important here, although I would prefer them to
have the same name (what are namespaces for :). Focus on getting the
design of throw/catch nailed down.

You can have a look around the NG and/or archives, this is not the first
question of it's kind here.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Jon Skeet [C# MVP]]

Tim Haughton <ti*********@gm ail.com> wrote:

I have a control that does employee lookups, auto complete of the name
etc.
The employee class takes an employee ID as one of its constructors, so
if you pass it an ID number for an employee that doesn't exist (for
example -1 or 100000000), it throws an exception:
Company.Busines s.EmployeeNotFo undException

As a general rule, it's simply not cricket (excuse analogy - we've just won
the ashes) to have constructors throw exceptions. A better idea would be a
static factory method called FromID or something similar.

While that may have been true in C++, there's no problem throwing
exceptions in C#. It's all over the framework - what would you expect
new FileStream (null, 0) to do, for instance?

Now my dilema is what to do when my application passes an invalid ID
number to my control EmployeeLookupC ontrol. The lookup control catches
the EmployeeNotFoun dException.

Why not throw an ArgumentExcepti on and pass in the EmployeeNotFoun dException
as the inner exception?

That sounds like a good idea to me.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[cmay]

Not sure.

From a programming standpoint, there would be no problem with it, other

than adding the necessity that the application reference the underlying
DLL that the exception belongs to.

But more from a design standpoint, it felt wrong to have a dll throwing
exceptions from another dll. Maybe not.

[cmay]

Thanks guys.