locked
Can anyone recommend an accepted source for... RRS feed

  • Question

  • Hi,

    I wonder if you read a book or source on the net that outlines in detail how to properly architecture and handle exceptions in n-tier WPF/WCF applications.

    I am coding a serious program with what seems to become lots of lines of code. I'd like some guidance about best practices, architecture and such for handling exceptions, throwing exceptions, what not to do's etc. I program in VB. I have enough understanding about validation, exception handling, and clean-up coding in wpf/wcf to be able to manage daily business so I am no looking for rookie guides.

    Having said that and to express my wishes: I have been reading a lot of fragments on Exception Handling and validation over the years but find it hard to summarize and come to an airtight policy for the N-TIER program that I am working on.


    Tsadok

    • Moved by Yves.Z Thursday, February 10, 2011 9:27 AM Architecture related (From:Windows Presentation Foundation (WPF))
    Sunday, January 30, 2011 7:25 AM

Answers

  • Thx All for your replies.

    I think I have stumbled on one of many programming subjects that have been discussed very thoroughly, but never properly documented in a one-stop-shopping concept (publishers take your Q from this). In my particular case (WPF - WCF - nTier Application) I have used the following approach for the UI Layer:

    1. All forms in need of validation are using IDataErrorInfo with adjusted tooltips and recognizable alerts. I refuse to enable a save button unless code is validated. 
    2. I have ran all possible scenarios and checked/tested my code, in such preventing ArgumentExceptions, NullReferenceExceptions, OutOfRangeExceptions etc.
    3. I have built an error class library with all possible method exceptions for each code block. That class I further subdivided into Fatal Errors (program terminates), Errors require none/some user interaction but do not terminate program, and finally Errors that require a future fix.
    4. I have hard coded and error number for each exception thrown anywhere. E.g. a FileNotFoundException in code block x has error code 0001, and a FileNotFoundException thrown in another block has the same exception handling code but a different error code. This way I know exactly what code was executed.
    5. I have built a notification library class for interaction with the user. This class will report actions taken by user and communicate those actions (which could proably lead to errors) to a log for the System Administrator. The second level of that class is reporting actions taken by user to user in a fancy - non-technical way. E.g. : "New User Added", when inserting a record was successful. But not: "You clicked on x-button"... (duh!)
    6. I have built a secure error log system (encrypted and sent with transport security SSL) with two layers of "couldn't report the error" fall back safety. (we're talking central administration by a Sys Admin - logs are send to a central location.). That system is further divided into: a user level log with reporting feature, and a System Admin log with thorough explanation of what is going wrong at the time of an error on any of the machines in a network of program users.
    7. I have programmed a program startup and pogram recovery error reporting system of logged events/errors and a double fallback system for that as well. Just in case the just in case failed earlier.
    8. I coded a 'send error report' feature, allowing users to report the error to me on the spot.

    As a general (rookie) advice for those following this subject:

    I have systematically checked every method (MSDN) for possible exceptions that could occur in the UI Layer and tested them before considering code as fit for my solutions. I have written procedures to deal with them and programmed clean-up code where possible. I have tested these fail-over features over and over and properly logged their outcome. (this is to create a technical help file/knowledgebase before program release.)

    After reading a lot on exception and error handling, 1 thing became utterly clear to me: any knowledge leading to an error and proper reporting on the error itself, no matter how small the error is - is very important for both programmer and user. Just catching the general (Ex) exception messages and displaying that in a message box to the user feels like cheating.

    Catching the exact error when it occurs and dealing with it - before it domino's into a users nightmare experience (the extra click on the mouse), led me to not rely blindly on the built-in WPF error bubbling system (the: oh the dispatcher will catch it mentality). Yes it does add many nested try-finally and Select Case blocks but better safe than sorry.

    Errors resulting from errors causing more errors (sorry for that) - need to be logged properly. Building a catch for stacked errors enables you to quickly get to the point and thus to a better response to errors.

    Just an example for those not 'catching on': A FileNotFound Exception was thrown. You caught the exception, but your reporting feature resulted in a CommunicationException. Then the locally created logfile was not saved due an UnhandledAccessException. Your disaster fail-over code triggered but lead to an IOException. When you finally managed to properly report, the stack got lost and now you're scratching your head trying to find the cause of the initial exception. The example may be somewhat lame.

    Hierarchically programming for errors on errors on errors takes a lot of time which might not always be budgetted for. That is why programming a transparant library error class (one that you can use for all your apps), looks to me like a good investment.

    Exception coding is daunting I find, however considering my gain, it is worth the effort.

     

     


    Tsadok
    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    Friday, February 11, 2011 8:51 AM
  • Hmm I understand your requirements and I don't think I can be of any help. You seem to have the right idea in your second paragraph but I assume the classification of exceptions is usually defined by the consensus feeling of the development team. If no one here manages to offer you a solution to your problem I'd trust your instincts in how you've managed so far and possibly write an article about it so others can feed back how effective your exception implementations are.

    I hope you find a solution!

    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    Monday, January 31, 2011 10:08 PM
  • this read should help you : http://www.informit.com/articles/article.aspx?p=102315


    http://blog.saraf.me
    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    • Edited by Saraf Talukder Tuesday, April 19, 2011 10:19 PM
    Tuesday, February 1, 2011 4:17 PM
  • Hi Tsadok Blok,

     

    Based on my understanding you may get a better answer from the Architecture General forum:

    http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/threads

    I suggest you post your questions there.

     

    Have a good day!

     

     


    Yves Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    Tuesday, February 1, 2011 6:58 PM

All replies

  • Stick to some basic general rules which apply to developing applications of any complexity:

    • don't trust external data
    • only catch exceptions that you're expecting (never try catching an exception of generic type Exception)
    • never swallow exceptions (empty try catch block)

    If you're really this concerned then you should look to whoever sets your coding standards and they should have a document to answer your questions. If you don't have one then the simple answer is be sensible . Do  your range checks, validate and clean your data etc. etc. To be honest (I probably shouldn't admit this) I very rarely implement my own exception handling, I always make sure I do substantial validation of data before I interact with it. If it doesn't pass, I chuck it straight back to wherever it came from until its fixed. But if you find yourself creating libraries built upon more of your own libraries then definitely do it!

    Have a look here

    The key to exception handling is finding the balance between doing it and not bloating your code so it becomes unreadible and hard to understand where you're going wrong in the first instance.

    Sunday, January 30, 2011 12:27 PM
  • Hi,

    Thank for your reply.

    As I said I am not looking for rookie examples of exception handling. I am more interested in a project policy that is airtight for an n-tier WCF/WPF application. Maybe I should elaborate a little:

    I need to structure security certificate exceptions (.509), all possible program exceptions, WCF Exceptions proxy exceptions like EndPointExceptions, CommunicationExceptions, but also SqlExceptions and IO Exceptions. I seperated exception code in Fatal errors (program terminates), error allowing clean-up, and errors that permit program to continue running which need only be logged for future release. I almost never get ArgumentExceptions or IndexOutOfRange, NullReference Exceptions in forms - my IDataErrorInfo is catching those.

    I'd like to program an all catching error class library to which exeptions are referred to - by using a simple statement like (throw 101) for both system and custom made exceptions. This way I could prevent coding multi line exceptions in each form repeating them x-times for each block.

    I am looking for proper architecture information on how to build this - if at all recommended, and what else I should use that I didn't think of in different scenarios e.g. memory and hardware corruption, file manipulation by users, issues when installing onto a networkdrive etc. A book or concise would be grate but I didn't find any usefull info that encompasses all..


    Tsadok
    Sunday, January 30, 2011 1:45 PM
  • Hmm I understand your requirements and I don't think I can be of any help. You seem to have the right idea in your second paragraph but I assume the classification of exceptions is usually defined by the consensus feeling of the development team. If no one here manages to offer you a solution to your problem I'd trust your instincts in how you've managed so far and possibly write an article about it so others can feed back how effective your exception implementations are.

    I hope you find a solution!

    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    Monday, January 31, 2011 10:08 PM
  • Thanks.

    Since this is a program that will be used by government law-offices I wanted to pass the architecture by the experts here. It is kind of a sensitive project so - for my own feeling, my instincts are just not enough - and we're all kinda nit-picking people I assume. But you could be right about there not being a one solution to exception handling in n-tier. I will consider writing a little articlle about it once the project is completed.


    Tsadok
    Tuesday, February 1, 2011 7:05 AM
  • this read should help you : http://www.informit.com/articles/article.aspx?p=102315


    http://blog.saraf.me
    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    • Edited by Saraf Talukder Tuesday, April 19, 2011 10:19 PM
    Tuesday, February 1, 2011 4:17 PM
  • Hi Tsadok Blok,

     

    Based on my understanding you may get a better answer from the Architecture General forum:

    http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/threads

    I suggest you post your questions there.

     

    Have a good day!

     

     


    Yves Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    Tuesday, February 1, 2011 6:58 PM
  • Thx All for your replies.

    I think I have stumbled on one of many programming subjects that have been discussed very thoroughly, but never properly documented in a one-stop-shopping concept (publishers take your Q from this). In my particular case (WPF - WCF - nTier Application) I have used the following approach for the UI Layer:

    1. All forms in need of validation are using IDataErrorInfo with adjusted tooltips and recognizable alerts. I refuse to enable a save button unless code is validated. 
    2. I have ran all possible scenarios and checked/tested my code, in such preventing ArgumentExceptions, NullReferenceExceptions, OutOfRangeExceptions etc.
    3. I have built an error class library with all possible method exceptions for each code block. That class I further subdivided into Fatal Errors (program terminates), Errors require none/some user interaction but do not terminate program, and finally Errors that require a future fix.
    4. I have hard coded and error number for each exception thrown anywhere. E.g. a FileNotFoundException in code block x has error code 0001, and a FileNotFoundException thrown in another block has the same exception handling code but a different error code. This way I know exactly what code was executed.
    5. I have built a notification library class for interaction with the user. This class will report actions taken by user and communicate those actions (which could proably lead to errors) to a log for the System Administrator. The second level of that class is reporting actions taken by user to user in a fancy - non-technical way. E.g. : "New User Added", when inserting a record was successful. But not: "You clicked on x-button"... (duh!)
    6. I have built a secure error log system (encrypted and sent with transport security SSL) with two layers of "couldn't report the error" fall back safety. (we're talking central administration by a Sys Admin - logs are send to a central location.). That system is further divided into: a user level log with reporting feature, and a System Admin log with thorough explanation of what is going wrong at the time of an error on any of the machines in a network of program users.
    7. I have programmed a program startup and pogram recovery error reporting system of logged events/errors and a double fallback system for that as well. Just in case the just in case failed earlier.
    8. I coded a 'send error report' feature, allowing users to report the error to me on the spot.

    As a general (rookie) advice for those following this subject:

    I have systematically checked every method (MSDN) for possible exceptions that could occur in the UI Layer and tested them before considering code as fit for my solutions. I have written procedures to deal with them and programmed clean-up code where possible. I have tested these fail-over features over and over and properly logged their outcome. (this is to create a technical help file/knowledgebase before program release.)

    After reading a lot on exception and error handling, 1 thing became utterly clear to me: any knowledge leading to an error and proper reporting on the error itself, no matter how small the error is - is very important for both programmer and user. Just catching the general (Ex) exception messages and displaying that in a message box to the user feels like cheating.

    Catching the exact error when it occurs and dealing with it - before it domino's into a users nightmare experience (the extra click on the mouse), led me to not rely blindly on the built-in WPF error bubbling system (the: oh the dispatcher will catch it mentality). Yes it does add many nested try-finally and Select Case blocks but better safe than sorry.

    Errors resulting from errors causing more errors (sorry for that) - need to be logged properly. Building a catch for stacked errors enables you to quickly get to the point and thus to a better response to errors.

    Just an example for those not 'catching on': A FileNotFound Exception was thrown. You caught the exception, but your reporting feature resulted in a CommunicationException. Then the locally created logfile was not saved due an UnhandledAccessException. Your disaster fail-over code triggered but lead to an IOException. When you finally managed to properly report, the stack got lost and now you're scratching your head trying to find the cause of the initial exception. The example may be somewhat lame.

    Hierarchically programming for errors on errors on errors takes a lot of time which might not always be budgetted for. That is why programming a transparant library error class (one that you can use for all your apps), looks to me like a good investment.

    Exception coding is daunting I find, however considering my gain, it is worth the effort.

     

     


    Tsadok
    • Marked as answer by Tsadok Blok Friday, February 11, 2011 8:57 AM
    Friday, February 11, 2011 8:51 AM