| > |
Blog entries about: Exception Management |
|
|
Create a SQL Database Programmatically
|
|
In this article I will explain how to use MS SQL Management Objects (SMO) to create a MS SQL database from C# code. In this sample will
- Enumerate all the SQL servers in the network and fill a list box where the user can select one of the servers.
- The user will enter the Database Name to create.
- The user will enter an AD account to grant right to.
- When the user click "Create Database" the system will check for the existence of the database.
Read More..
|
|
|
An Extensible Light Xml Rules Engine Component
|
|
The Extensible light XML rules engine component allows the easy configuration of rules in XML, definition of the interpretations of rules and the actions to be taken by client code. Though the component idea is simple its extensibility and completeness makes it worth of reuse. The component is developed in C# and .Net framework. Read more..
|
|
|
Designing Exception Management
|
|
All applications will have errors occur during their operation, both expected and unexpected types of errors. When errors occur, how should they get handled by the application?
What makes exception management challenging:
- There are issues with determining who gets notified of errors, is it always the user?
- Security people are quick to point out that error messages can include information that could be used for compromising the system. The classic example being “connection string X failed” and the connection string contains the database username and password.
- System administrators need to know when problems are happening, but do they need to know about every error? Error reporting to the system administrator can actually be very complex because it could be a group of system administrators or even include the business owners of the application. So there might be a whole workflow to how errors get reported to the people who own and maintain the application.
- How should errors be propagated within the architecture? Are errors always handled at the closest point to where they occur, or use some kind of global exception handling?
Best Practices in handling exception management:
- Categorizing errors as “business” versus “technical” errors is necessary to support sophisticated exception management.
- Sometimes exceptions are not necessarily errors, but are expected and the business logic takes an alternate successful path, and so in those cases the exception can be handled locally in the code where they occur. Otherwise exceptions are propagated up until it reaches the system boundary where a global exception handler reacts to the exception.
- The propagation is done using normal .NET try/catch/throw exception handling. Developers sometimes think about using error codes because of older C style conventions or concern over performance of .NET exception handling, but performance for failed requests typically isn’t an issue.
- Business exceptions get raised by the business logic when errors such as a business rule violation or validation error occurs. Business exceptions are also always raised with a safe and user acceptable message.
- At the system boundary in the global exception handler, all technical exceptions should be logged for the system administrator and include a unique log id. The message returned to the user should be replaced with a generic error message so unsafe information does not get leaked out of the system. But the generic error message must include the unique log id entry, so if the user contacts the system administrator for help, then the administrator can determine the actual technical error message by looking up the log entry using the unique id. This saves time and prevents the system administrator from having to ask the user what time the error happened, can they reproduce the error again, etc.
|
|