Difference between revisions of "System Architecture"
Jump to navigation
Jump to search
(→Help =) |
|||
| Line 138: | Line 138: | ||
=== Error Handling === | === Error Handling === | ||
| − | + | ||
| − | + | When an error is discovered an exception is thrown. Built-in exceptions can be used if appropriate, such as <tt>ArgumentException</tt>, <tt>ArgumentNullException</tt>, and <tt>InvalidOperationException</tt>. In other cases Heureka specific exceptions, inheriting from <tt>ApplicationException</tt>, are used | |
| − | + | ||
| − | + | Code that depends on exceptions in the normal flow should be avoided. For instance, if a string should be checked for a valid number it is better to use | |
| − | + | <tt>int.TryParse()</tt> than <tt>int.Parse()</tt> as the latter throws an exception of the string not is numeric. When designing classes, consider implementing similar methods allowing clients to determine beforehand if an operation is valid or not. | |
| + | |||
| + | Exceptions should only be caught if they are to be handled, and only those exceptions that are relevant should be caught. Do not just catch and re-throw exceptions. This leads to poor performance and also destroys the call stack of the exception. | ||
| + | |||
| + | In the user interface there must be an exception handler for all code that might throw exceptions. That code should show an error message to the user if an exception is caught. Use <tt>Slu.Heureka.BaseLayer.HeurekaForms.ErrorDialog</tt> to show error messages. | ||
| + | |||
| + | The exception message should be brief. If a longer description is needed, set the <tt>HelpLink</tt> for the exception. | ||
| + | |||
=== Kommandon === | === Kommandon === | ||
Design-mönstret Command används för att kapsla in åtgärder användaren utför i egna objekt. | Design-mönstret Command används för att kapsla in åtgärder användaren utför i egna objekt. | ||