The general rule is
1. if you can't handle the exception don't.
2. If you are doing business logic throw a custom exception for when you need
to fail a process.
3. Inherit from exception and do not use application exception.
I think your code falls into rule 1.
It's up to the ui to catch and
I just wanted to throw in Krzysztof Cwalina s blog
Check his post on Choosing the Right Type of Exception to Throw
http://blogs.msdn.com/b/kcwalina/archive/2005/03/16/396787.aspx
.peter.gfader.
http://blog.gfader.com/
http://twitter.com/peitor
On Wed, Jun 9, 2010 at 4:04 PM,
Bec, you seem to own the code that makes the report and it's a part of your
project, it doesn't sound like a reusable black box library. I'd treat
each of these cases differently. The Framework Design Guidelines book
explains all of this clearly, and I highly recommend everyone in here keep a
copy
Hi Greg, you've hit the nail right on the head. I always tend to
create black box classes even when they are specific to a single
project which complicates things and wastes my time. I have now seen
the error in my ways. Cheers
Thanks everyone for the help!
--Bec--
On Thu, Jun 10, 2010 at 9:43
Hi Bec,
I try to approach these problems pragmatically. I'm unaware of your development
environment, deadlines etc. So, pragmatically I say just to do the bare minimum
to start with. For me that would be to let the caller of the class handle the
exceptions they care about. Once you have some
Well actually its currently the former, the caller passes in the temp
directory for the report generator to use. I did it like this because
the report generator is a separate assembly (a class library) so the
caller reads the configured value from the app.config and passes it in
to the library. Is
On Wed, Jun 9, 2010 at 11:59 AM, Bec Carter bec.usern...@gmail.com wrote:
Hi!
From the more experienced programmers here, when is it appropriate to
create custom exceptions?
I am finding a mix of opinions around.
eg. I have a class which generates reports. Part of the process is to
create
