S
Steve - DND
I was wondering if anyone can point me to some articles or practices they
use for dealing with errors in their applications; particularly in an n-tier
design. I am trying to find one way to conveniently handle both soft and
hard errors, primarily for display to the end user.
One method I have considered is rethrowing exceptions. With this approach, I
would throw a plain old ApplicationException, with the Message property as
the polite message for the user, and the InnerException as the exception
that actually occurred(although this might not be necessary, since the
actual error would be immediately logged for debugging purposes). The major
drawbacks I have seen with this, is that it appears to be a frowned upon due
to extra resource usage(does anyone have any hard figures?), and that
exceptions should be used for exceptional happenings(meaning that failing a
security check shouldn't mean an exception is thrown). One other major issue
is that it is difficult(if not impossible) to use in a scenario where some
steps in a process can fail and should be reported, but they do not mean
that the whole process failed.
The other method I have considered is maintaing an error collection that is
populated with errors when they occur, and passed around the business layer,
and data layer. This seems like the way to solve the issue of multiple steps
failing, and not adding the additional resource consumption by throwing
errors. The major issue it does bring up is that after every call to the BL,
we must check the error collection for errors, and output them if need be,
and stop further processing if necessary. Although this could be wrapped up
with a call to a static function somewhere after each call to the BL, it
still seems like it would be a maintenance nightmare in the future.
Any thoughts, ideas, current practices, or articles would be most
appreciated.
Thanks,
Steve
use for dealing with errors in their applications; particularly in an n-tier
design. I am trying to find one way to conveniently handle both soft and
hard errors, primarily for display to the end user.
One method I have considered is rethrowing exceptions. With this approach, I
would throw a plain old ApplicationException, with the Message property as
the polite message for the user, and the InnerException as the exception
that actually occurred(although this might not be necessary, since the
actual error would be immediately logged for debugging purposes). The major
drawbacks I have seen with this, is that it appears to be a frowned upon due
to extra resource usage(does anyone have any hard figures?), and that
exceptions should be used for exceptional happenings(meaning that failing a
security check shouldn't mean an exception is thrown). One other major issue
is that it is difficult(if not impossible) to use in a scenario where some
steps in a process can fail and should be reported, but they do not mean
that the whole process failed.
The other method I have considered is maintaing an error collection that is
populated with errors when they occur, and passed around the business layer,
and data layer. This seems like the way to solve the issue of multiple steps
failing, and not adding the additional resource consumption by throwing
errors. The major issue it does bring up is that after every call to the BL,
we must check the error collection for errors, and output them if need be,
and stop further processing if necessary. Although this could be wrapped up
with a call to a static function somewhere after each call to the BL, it
still seems like it would be a maintenance nightmare in the future.
Any thoughts, ideas, current practices, or articles would be most
appreciated.
Thanks,
Steve