|
This article is part of Quick start tutorials series.
This is short dictionary of terms used in this help file.
| • | Bug - (see also: Error, Crash) is a software defect. It is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most Bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of Bugs, and/or Bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing Bugs in a program are commonly known as Bug reports, fault reports, problem reports, trouble reports, change requests, and so forth. Many people mistakes Exceptions for Bugs and visa versa, but it's obviously wrong, since Leak is an Bug too. And not all Exceptions are real Bugs in your code. For example, you can handle out of disk space exceptions in your code and ask user to free disk. There is no bug in your code. |
| • | Bug report - (see also: Unhandled exception) a report about possible Bug in the application. It usually contains information about Exception or Leak. Bug report usually contains one or more Call stacks and some information about system itself and application. Bug reports are stored in files. Often one file can hold multiple Bug reports. EurekaLog's Bug reports have .el, .elp, .elx file extensions. The .el files are usual text files, which can be opened in any text editor. However, EurekaLog Viewer can be used to view them in more convenient way. See also: reading and understanding bug reports. |
| • | Build Configuration - build configurations consist of options that you can set on all the build-related pages of the IDE's Project > Options dialog box. Build configurations are saved in the project file (such as .dproj or .cbproj). Base, Debug, and Release are the three default build configurations. A developer can define more configurations. |
| • | Call stack - stack data structure that stores information about the active subroutines of the application. This kind of stack is also known as an execution stack, control stack, run-time stack, or machine stack, and is often shortened to just "the stack". Call stack is a central piece of information in any Bug report. Call stack is a sequence of addresses (mostly with textual description - see Debug information), which leads us to place of the problem (Exception or Leak). See also: Call stacks. |
| • | Chained exception - (see also: Nested exception) is Exception which was raised inside Exception handler. |
| • | Crash - (see also: Unhandled exception, Bug, Error) is the termination of the process by the OS due to a real Unhandled exception. |
| • | Deadlock - a situation when two or more threads are waiting for each other infinite. Such cases are Bugs in the application. This is a special case of Hang. |
| • | Debug information - (see also: Injecting) is information about link between machine's binary code (.exe/.dll/.bpl file) and source code (.pas file). It's used to build human-readable Call stacks. Debug information is necessary for EurekaLog to function. It's generated by linker and is saved into .map or .tds files. It's injected into your Executable during post-processing stage. See also: EurekaLog's basics. |
| • | EDD - see Exception Driven Development. |
| • | Error - (see also: Exception, Crash) see Bug. Many people mistakes Exceptions for Errors and visa versa, but it's obviously wrong, since Leak is an Error too. And not all Exceptions are real Errors in your code. Sometimes Error can be used as synonym of Exception, not Bug. It's usually best to avoid this term due to its vague meaning. Use either Bug or Exception. |
| • | Exception - this is an event which interrupts normal execution path of your code and passes control to Exception handler. Also, Exception is a object which describe exception event. The process of generating Exception and interrupting your code is called "raising exception" or "throwing exception". Exceptions are raised in case of unexpected or unusual cases. Sometimes (but not always!) Exceptions are Errors. For example, "access denied" exception when opening text document in text editor is not a bug in your code, there is nothing to fix. On the other hand, "access violation" exception during the same process of opening is clearly your bug. Exceptions can be Handled or Unhandled. Exceptions also can be Hardware or Software. |
| • | Exception Driven Development (EDD) - is a software development process that relies on the capturing software crash and hang data from end-users. You ship your software and analyze incoming bug reports, fix few top bugs and release an update. Repeat iteration again. See also: typical use of EurekaLog. This approach is not self-suffice and it can and should be combined with other technics, such as TDD, DDD, XP/Agile, etc. |
| • | Exception handler - (see also: Exception) is a piece of code which gets control when an Exception was raised. It's usually not Hook. Exception handler either perform cleanup (try-finally) or Exception handling (try-except). |
| • | Exception handling - (see also: Exception) usually refers to the process of "dealing with Exceptions". Exception handling includes processing of Exception such as logging, showing error message, using fallback actions and so forth. Exception is destroyed after Exception handling is finished. Exception handling occurs inside try-except blocks. See also Handled exception and Unhandled exception. |
| • | Exception log - see Bug report. |
| • | Exception tracer - (see also: Exception) a tool which install Hooks and intercepts the raising of Exceptions and allow user to create Bug report for each Unhandled exception. Often Exception tracers have additional functionality. Like collecting information, debug features, Leaks reporting and so on. EurekaLog is an Exception tracer tool. |
| • | Executable - see Executable module. |
| • | Executable module - in short, it's .exe, .dll or .bpl file. Basically, it's your compiled project. It's any file that can be executed (can run code). |
| • | Handled exception - (see also: Exception) is an Exception, which was handled by Exception handling process. I.e. this is Exception which was processed by an Exception handler. |
| • | Hang - this is situation when application stops responding. This can be a Bug in application, but not always. Permanent (endless) Hang is always a Bug. A special case of Hang is Deadlock. |
| • | Hardware exception - (see also: Exception, Software exception) is an Exception, which is triggered by hardware (like CPU, for example). This type of Exception are async Exceptions - they can be raised at any place and any time. Access violation (EAccessViolation) is an example of Hardware exception. In Delphi: all Hardware exceptions are wrapped into exception class delivered from EExternalException. |
| • | Hook - a block of code which is called instead or before other code's block. A special case of Hook is a simple event/event handler. Usually documented way to call some interceptor code is called "event" and handler is called "event handler". If there is no documented way to intercept code - then it's called Hooking and Hook. |
| • | Hooking - (see also: Hook) the process of installing and using Hooks. Sometimes it's called Injecting, when it specifically refers to undocumented way to intercept code. |
| • | Injecting - have different meaning. Can refer to Hooking (as the process of installing Hooks) or to the process of embedding Debug information into Executable module. |
| • | Leak - is a Bug in application when application consumes some kind of resource but is unable to release it back to the operating system. If this resource is memory - then Leak is called Memory leak. |
| • | Memory leak - (see also: Leak) is a type of Leak when application captures and don't release memory (usually meaning virtual memory). |
| • | Module - see Executable module. |
| • | Nested exception - (see also: Chained exception) is the original exception, which has triggered Chained exception. |
| • | Resource leak - (see also: Leak) any Leak which is not Memory leak. "Resource" can be bitmaps, kernel objects and even other types of "memory". |
| • | Software exception - (see also: Exception, Hardware exception) is an Exception, which is triggered by the code. This type of Exception are sync Exceptions - they can be raised only at specific places, when code has a command to raise Exception. EStreamError is an example of Software exception. This is most common Exception type in applications. |
| • | Unhandled exception - (see also: Exception) may have two different meanings. Usually, Unhandled exception is an Exception which is not Handled exception. However, the amount of "handling" meaning produces different usage cases of "Unhandled exception" term: |
| o | Default meaning is this: Unhandled exception escapes any handling code and elevates up to operating system code. Such Exceptions means unavoidable death of the process (application) - unless there is some Hook for Unhandled exceptions. This is a usual meaning of Unhandled exception in standard applications. |
| o | However, when application is enabled by Exception tracer, Unhandled exception gets second meaning - it now usually means Exception that escapes your Exception handlers and it's caught by Exception tracer (usually via Hooks). Event though technically Exception is Handled exception in this case - it's still can be called Unhandled exception. The previous case is named "real unhandled exception". Real unhandled exception is a very rare case for application with Exception tracer. |
| • | Unit - Delphi's .pas file or C++ Builder's .cpp file. |
|
Send feedback...
|
Build date: 2023-09-11
Last edited: 2023-08-31
|
PRIVACY STATEMENT
The documentation team uses the feedback submitted to improve the EurekaLog documentation.
We do not use your e-mail address for any other purpose.
We will remove your e-mail address from our system after the issue you are reporting has been resolved.
While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback.
After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.
Permanent link to this article: https://www.eurekalog.com/help/eurekalog/terms.php
|
|
