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.Controls.Web.LookupControls.EmployeeLookupControl

Now I have a Employee class:
Company.Business.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.Business.EmployeeNotFoundException

Now my dilema is what to do when my application passes an invalid ID
number to my control EmployeeLookupControl. The lookup control catches
the EmployeeNotFoundException.

One part of me thinks that it should simply rethrown the
EmployeeNotFoundException, 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 EmployeeNotFoundException
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.Business.EmployeeNotFoundException
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 EmployeeNotFoundException. 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]

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.Business.EmployeeNotFoundException

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 EmployeeLookupControl. The lookup control catches
the EmployeeNotFoundException.

Why not throw an ArgumentException and pass in the EmployeeNotFoundException
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]

So to boil it down.
Option 1: Rethrow the Company.Business.EmployeeNotFoundException
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 ArgumentException 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 EmployeeNotFoundException,
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 SomethingWentWrongInMyModuleException, and
attach the original Exception to the .Inner of that. But this requires
anyone who wish to catch only EmployeeNotFoundException to catch
SomethingWentWrongInMyModuleException and inspect it's .Inner, not very
nice at all.

Sub Option 2a: Use the same name EmployeeNotFoundException. 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.

 

[Jon Skeet [C# MVP]]

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?

Why not throw an ArgumentException and pass in the EmployeeNotFoundException
as the inner exception?

That sounds like a good idea to me.

 

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