I think we have all been there sending e-mails when errors occurs. It always
seems such a good idea at the time, and probably was in the day because
beforehand we probably just showed the user the error and expected a phone
call. I worked for a company 6-7 years or so ago where I had to do support
24/7 on a rotation and the policy there was similar to yours. Thank God I
left.
My current job required me to take over some code that had been written by
3rd party suppliers, and is probably the reason I'm dead against CSLA as
thats what they attempted to use. Lets just say they had 8 different user
model classes where each type was in-fact identical and they had created
different classes to represent user relationships with other classes. Anyway
I understand what place you are in at the minute. I find when stuff is
getting too much for my head to manage it can be useful to create a set of
class diagrams and reach for a UML book to tidy up your mind before
continuing.
Any more questions you have feel free to ask them mate.
Oh and back on topic.
The reason I say only provide custom exceptions if you are using a
framework
is because 99% of the time the only person viewing an exception will be
the
developer and providing developers with erros is a good thing.
99% of time an exception/failure to do something should be handled by BLL
and not present the error to the user. So the user just understands that
his
Update to the database failed, all he wants to know then is that it failed
and whether he can try again. Not that his error occured because of a
deadlock in the DB......, so providing a custom error to suit users
generalizes the error which is then no good for the developer.
I tend to find as a developer the Stack Trace is more important for
debugging than anything even the actual error message sometimes. The
problem
is incorrect use of custom exception can hide this stack trace and correct
use is very very time consuming.
I want to thank Pete and you for your encouragement. I start feel
alone in my cubical some days. My coworkers don't generally know or
care about these low-level details. For the past year or more, our
users have been using a new user interface. Every time they screw up
and leave out a field or try to recreate an existing record, we get an
email with a stack trace and the error message. We probably get close
to 10 of these a day and we only have about 11 users. In the next few
months, the number of users will probably be closer to 100. I can't
image how many emails I'll be getting then.
The problem is the way we do things: backwards. My lead developer
believes that we should let the database catch the majority of the
user's mistakes. Instead of our UI telling them to fill in a field, we
let constraints on the database handle it for us. In cases like that,
I just want to scream. The user doesn't know what an ORA-00001 error
is and a message like "Unique Contraint Violation on PK_001_CUPK"
really doesn't help them. The fact the UI doesn't handle this is
absurd in my opinion. It was al right when we only have a couple
users. However, when you start seeing the same error 10 times a day,
you know something has to be done about it.
Of course, I'm not going to take the time to write the code that
translates every Oracle error into a user-friendly message. I'm going
to spend my time adding validation to the UI. I kind of have to weigh
out what I can leave to the database and what I should check in the
UI. Unique constraints are a little impractical to check in some
cases. However, I can probably handle missing fields fairly easily. I
would like to know that when 100 users are using my system that I
still only get 10 messages a week.
This user interface was redesigned from Oracle Forms into Windows
Forms. My lead developer said to me, "The user interface will have a
clean separation of layers: a three-layer architecture."
Unfortunately, his interpretation was a little off. We have DataTables
that are created and manipulated inside the code behind. He bound text
boxes to rows in code by maintaining row indexes. Each form was
thousands of lines long. He wan't using binding correctly at all. I've
fixed a lot of it since then, but it is still highly dependent on
DataTables being in the code behind. Recently I got him to agree to
allow me to move the code I wrote for the other subsystems into the UI
(no more maintaining the code set under two source control folders for
me!). I plan to use that code to rework some of the forms that are
causing us our problems. I just need his approval. This will probably
be the week where the form completely bombs and needs fixed anyway.
Eventually, the entire system should be a little more consistent and
hopefully less buggy. I can start making the UI a little more
versitile then. I'm kind of racing against the clock: will the system
start getting used more first? or will I stablize the system first?
What's funny is that ever since I started using this new code set,
I've rewritten close to a quarter of the entire system in less than 3
months. That's 10 separate applications! That's says something for
taking the time to do design. I will probably redo the reporting and
UI side of the application and be half way. Then I have to implement
the two power bill calculators and the system will be completely
upgraded. I'm expecting the UI and reports to take about 3-5 months.
Each of the calculators could take that long, too. They are still
written in C/C++ from the 80's (global variables anyone?).
Is there any wonder why I am paranoid about making a mistake? It'll be
biting me in the butt for years!
