Coding by exception: Difference between revisions
Jackmcbarn (talk | contribs) m combine duplicate refs |
→Accidental complexity: remove off-topic section which also duplicates anti-pattern |
||
| Line 3: | Line 3: | ||
==Background== |
==Background== |
||
As a general rule, well designed software projects contain very few [[corner case]]s.<ref name="slideshare">http://www.slideshare.net/ExigenServices/anti-patterns-part-2</ref> There are a variety of [[software development methodology|software development methodologies]] that purport to help engineers develop software that avoid these corner cases. They typically address [[Dependency (computer science)|dependency management]] issues. [[Design pattern (computer science)|Design patterns]] are another tool for arriving at less of a 'one-off' solution. As a simple solution, programmers should avoid writing code to specifically handle an error and instead use a more generalized solution. [[exception handling|Exceptions]] were invented to keep a program running when simple errors are made and should not be improperly used. |
As a general rule, well designed software projects contain very few [[corner case]]s.<ref name="slideshare">http://www.slideshare.net/ExigenServices/anti-patterns-part-2</ref> There are a variety of [[software development methodology|software development methodologies]] that purport to help engineers develop software that avoid these corner cases. They typically address [[Dependency (computer science)|dependency management]] issues. [[Design pattern (computer science)|Design patterns]] are another tool for arriving at less of a 'one-off' solution. As a simple solution, programmers should avoid writing code to specifically handle an error and instead use a more generalized solution. [[exception handling|Exceptions]] were invented to keep a program running when simple errors are made and should not be improperly used. |
||
==Accidental complexity== |
|||
[[Accidental complexity]] is that complexity which arises in computer programs or the development process which is deemed not essential to the problem being solved. Coding by exception is an example of [[accidental complexity]]. Where this issue arises from poor planning or programming, some complexity is an [[essential| essential complexity]] and unavoidable. Here is a list<ref name="slideshare" /> of some programming accidental complexities: |
|||
*Incorrect Exception Usage: see below |
|||
*[[Accidental complexity]]: Introducing unnecessary complexity into a solution |
|||
*[[Action at a distance (computer science)|Action at a distance]]: Unexpected interaction between widely separated parts of a system |
|||
*[[Blind faith (computer science)|Blind faith]]: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine |
|||
*[[Boat anchor (computer science)|Boat anchor]]: Retaining a part of a system that no longer has any use |
|||
*[[Busy waiting]]: Consuming [[CPU]] while waiting for something to happen, usually by repeated checking instead of messaging |
|||
*[[Caching failure]]: Forgetting to reset an error flag when an error has been corrected |
|||
*[[Cargo cult programming]]: Using patterns and methods without understanding why |
|||
*Coding by exception: Adding new code to handle each special case as it is recognized |
|||
*[[Error hiding]]: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. Also can refer to erasing the [[Stack trace]] during exception handling, which can hamper debugging. |
|||
*[[Hard code]]: Embedding assumptions about the environment of a system in its implementation |
|||
*[[Lava flow (programming)|Lava flow]]: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences<ref>[http://www.antipatterns.com/lavaflow.htm Lava Flow] at antipatterns.com</ref><ref>{{cite web |url=http://www.icmgworld.com/corp/news/Articles/RS/jan_0202.asp |title=Undocumented 'lava flow' antipatterns complicate process |publisher=Icmgworld.com |date=14 January 2002 |accessdate=3 May 2010}}</ref> |
|||
*[[Loop-switch sequence]]: Encoding a set of sequential steps using a switch within a loop statement |
|||
*[[Magic number (programming)#Unnamed numerical constants|Magic numbers]]: Including unexplained numbers in algorithms |
|||
*[[Magic string (programming)#Magic strings in code|Magic strings]]: Including literal strings in code, for comparisons, as event types etc. |
|||
*[[Don't Repeat Yourself|Repeating yourself]]: Writing code which contains repetitive patterns and substrings over again; avoid with [[once and only once]] (abstraction principle) |
|||
*[[Shotgun surgery]]: Developer adds features to an application codebase which span a multiplicity of implementors or implementations in a single change. |
|||
==Incorrect exception usage== |
==Incorrect exception usage== |
||
Revision as of 06:56, 29 July 2015
Coding by exception is an accidental complexity in a software system in which the program handles specific errors that arise with unique exceptions. When an issue arises in a software system, an error is raised tracing the issue back to where it was caught and then where that problem came from, if applicable. Exceptions can be used to handle the error while the program is running and avoid crashing the system. Exceptions should be generalized and cover numerous errors that arise. Using these exceptions to handle specific errors that arise to continue the program is called coding by exception. This anti-pattern can quickly degrade software in performance and maintainability.
Background
As a general rule, well designed software projects contain very few corner cases.[1] There are a variety of software development methodologies that purport to help engineers develop software that avoid these corner cases. They typically address dependency management issues. Design patterns are another tool for arriving at less of a 'one-off' solution. As a simple solution, programmers should avoid writing code to specifically handle an error and instead use a more generalized solution. Exceptions were invented to keep a program running when simple errors are made and should not be improperly used.
Incorrect exception usage
Often coding by exception can lead to further issues in the software with incorrect exception usage. In addition to using exception handling for a unique problem, incorrect exception usage takes this further by executing code even after the exception is raised. This poor programming method resembles the goto method in many software languages but only occurs after a problem in the software is detected.