This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:start [2021/11/07 01:17] nick ↷ Links adapted because of a move operation |
dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:start [2022/05/27 19:40] (current) nick grammar |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== Overview ===== | ===== Overview ===== | ||
| - | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers | Return to Top]] | + | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:start| Return to Top]] |
| Any particular operation within an Object is generally [[dido:public:ra:xapend:xapend.a_glossary:i:imperative | Imperative]] in nature. This means that the Operations are composed of a set of statements. As the program steps through the Operation and executes each statement (i.e., instruction) the state of the Object is changed. Some statements change the values of the **Field Data** while others change the flow of execution through [[dido:public:ra:xapend:xapend.a_glossary:c:control_flow]] operations (i.e., **''IF / ELSE IF / ELSE / ENDIF''**, or **''FOR LOOPS | WHILE LOOPS /''**, etc.). | Any particular operation within an Object is generally [[dido:public:ra:xapend:xapend.a_glossary:i:imperative | Imperative]] in nature. This means that the Operations are composed of a set of statements. As the program steps through the Operation and executes each statement (i.e., instruction) the state of the Object is changed. Some statements change the values of the **Field Data** while others change the flow of execution through [[dido:public:ra:xapend:xapend.a_glossary:c:control_flow]] operations (i.e., **''IF / ELSE IF / ELSE / ENDIF''**, or **''FOR LOOPS | WHILE LOOPS /''**, etc.). | ||
| - | As the statements are executed, the **''Program Counter''** for the Operation is also modified. **Note:** Rarely all the statements contained within a single operation, but relies on calling and executing other Operations. Therefore, most Operations are also considered a [[dido:public:ra:xapend:xapend.a_glossary:p:procedurallanguage]]. Figure {{ref>ImperativeProcedural}} provides a graphic of the difference between **Imperative** and **Procedural** Programs. | + | As the statements are executed, the **''Program Counter''** for the Operation is also modified. **Note:** Rarely are all the statements contained within a single operation, but relies on calling and executing other Operations. Therefore, most Operations are also considered a [[dido:public:ra:xapend:xapend.a_glossary:p:procedurallanguage]]. Figure {{ref>ImperativeProcedural}} provides a graphic of the difference between **Imperative** and **Procedural** Programs. |
| <figure ImperativeProcedural> | <figure ImperativeProcedural> | ||
| Line 14: | Line 14: | ||
| </figure> | </figure> | ||
| - | To confuse the situation even more, there is a differentiation between the Imperative or Procedural: function, procedure, and method. | + | To confuse the situation, even more, there is a differentiation between the Imperative or Procedural: function, procedure, and method. |
| | **function** | a named set of instructions that perform a task and return a single value to the caller of the function. Generally, all the parameters passed to the function are considered **''IN''** (i.e., Read-Only). | | | **function** | a named set of instructions that perform a task and return a single value to the caller of the function. Generally, all the parameters passed to the function are considered **''IN''** (i.e., Read-Only). | | ||
| Line 23: | Line 23: | ||
| ===== Exceptions ===== | ===== Exceptions ===== | ||
| - | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers | Return to Top]] | + | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:start| Return to Top]] |
| An important aspect of executing any set of instructions is **''What happens if there is an error?''**. | An important aspect of executing any set of instructions is **''What happens if there is an error?''**. | ||
| Line 30: | Line 30: | ||
| * **Access denied [[dido:public:ra:xapend:xapend.a_glossary:s:segfault]]** occurs when the user does not have privileges to a resource, such as a file, or when the resources are locked by some program or user. Other examples would be trying to access memory that is outside the current program space or trying to execute a null instruction. | * **Access denied [[dido:public:ra:xapend:xapend.a_glossary:s:segfault]]** occurs when the user does not have privileges to a resource, such as a file, or when the resources are locked by some program or user. Other examples would be trying to access memory that is outside the current program space or trying to execute a null instruction. | ||
| - | * **Device not ready** occurs when an external device is not ready or available. For example, a disk drive that has not been mounted, accessing a monitor that has been disconnected. The resource may have been powered down, disconnected, damaged, moved, deleted, or a had a fault. Alternatively, the resource as specified may simply might not exist (i.e., typographical errors in its name). | + | * **Device not ready** occurs when an external device is not ready or available. For example, a disk drive that has not been mounted, accessing a monitor that has been disconnected. The resource may have been powered down, disconnected, damaged, moved, deleted, or had a fault. Alternatively, the resource as specified may simply not exist (i.e., typographical errors in its name). |
| * **Low Disk Space** occurs when the disk system is full or nearly full. | * **Low Disk Space** occurs when the disk system is full or nearly full. | ||
| * **Out of memory** occurs when the system runs out of **Heap** and/or **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]]** memory. The system can not load new programs or functions (i.e., **Stack**) or execute the existing ones (i.e., **Heap** limit) | * **Out of memory** occurs when the system runs out of **Heap** and/or **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]]** memory. The system can not load new programs or functions (i.e., **Stack**) or execute the existing ones (i.e., **Heap** limit) | ||
| Line 36: | Line 36: | ||
| The error conditions could arise from runtime errors such as: | The error conditions could arise from runtime errors such as: | ||
| - | * **Dividing by zero** occurs when, during execution, an attempt is made to divide a number by zero. Because these types of errors can not be c=found at compile time, they occur at runtime. | + | * **Dividing by zero** occurs when, during execution, an attempt is made to divide a number by zero. Because these types of errors can not be c=found at compile-time, they occur at runtime. |
| - | * **Out of Bound** occurs when a program tries to access an element in an array that is out of range of the array. Many languages dimension arrays from 0 to +number), some allow negative indexing and others do not. | + | * **Out of Bound** occurs when a program tries to access an element in an array that is out of range of the array. Many languages dimension arrays 0 to +number), some allow negative indexing and others do not. |
| - | * **Type Mismatch** occurs when an attempt is made to store a value into an array that is not compatible (i.e., trying to store an integer in an array of strings). | + | * **Type Mismatch** occurs when an attempt is made to store a value into an array that is not compatible (i.e., trying to store an integer in an array of strings). |
| * **Range Error** occurs when a value does not meet the allowable range of values specified by the code. For example, trying to set a value of 200 into a value described by a percent type that ranges from 0 to 100. | * **Range Error** occurs when a value does not meet the allowable range of values specified by the code. For example, trying to set a value of 200 into a value described by a percent type that ranges from 0 to 100. | ||
| * **Number Format Error** occurs when an attempt is made to convert a string to a number, but the string does not match the described format. For Example, trying to convert the String **''"one"''** to a number. | * **Number Format Error** occurs when an attempt is made to convert a string to a number, but the string does not match the described format. For Example, trying to convert the String **''"one"''** to a number. | ||
| Line 44: | Line 44: | ||
| The error conditions could arise from syntax or semantic errors. **Note:** strongly typed systems avoid these errors) such as | The error conditions could arise from syntax or semantic errors. **Note:** strongly typed systems avoid these errors) such as | ||
| - | * **''Value must be an Unsigned Integer''** occurs when the basic types of parameters do not match. Usually this occurs when the code has change or the correct [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]] can not be found. | + | * **''Value must be an Unsigned Integer''** occurs when the basic types of parameters do not match. Usually, this occurs when the code has changed or the correct [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]] can not be found. |
| - | * **''Too Few Parameters''** occurs when the code tries to call a procedure, function or method that requires more parameters than can be found in the existing libraries. This can occur due to changes in the calling signature or when a [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]] is not found. | + | * **''Too Few Parameters''** occurs when the code tries to call a procedure, function, or method that requires more parameters than can be found in the existing libraries. This can occur due to changes in the calling signature or when a [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]] is not found. |
| * **''Class Not Found''** occurs when the code is trying to instantiate a class whose definition is not included in the current program or any of the other [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]]. | * **''Class Not Found''** occurs when the code is trying to instantiate a class whose definition is not included in the current program or any of the other [[dido:public:ra:xapend:xapend.a_glossary:s:shared_libraries]]. | ||
| * **''Interrupted''** occurs when one thread or process interrupts another thread or process. | * **''Interrupted''** occurs when one thread or process interrupts another thread or process. | ||
| - | In most modern [[dido:public:ra:xapend:xapend.a_glossary:o:oo]] languages ( i.e., Java, C#, C++, Python, etc.) these **Error Conditions** are processed through the use of **Exceptions**. When an error occurs, regardless of where, an [[dido:public:ra:xapend:xapend.a_glossary:e:exception]] is thrown which terminates the current process. Terminating the process amounts to "popping" the **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]]** for the most recent call and (if possible) releasing memory from the **Heap**. This processes of unwinding the **Stack** and the **Heap** until the **Exception** is caught by an [[dido:public:ra:xapend:xapend.a_glossary:e:exception_handler]] programmed to handle the particular kind of error thrown. If an **Exception Handler** is encountered that does not handle the error, the exception is rethrown until an **Exception Handler** is found that does handle the error or the program **Stack** is empty (nothing left to pop), which terminates the program and control reverts to the [[dido:public:ra:xapend:xapend.a_glossary:o:os]]. | + | In most modern [[dido:public:ra:xapend:xapend.a_glossary:o:oo]] languages ( i.e., Java, C#, C++, Python, etc.) these **Error Conditions** are processed through the use of **Exceptions**. When an error occurs, regardless of where an [[dido:public:ra:xapend:xapend.a_glossary:e:exception]] is thrown which terminates the current process. Terminating the process amounts to "popping" the **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_memory]]** for the most recent call and (if possible) releasing memory from the **Heap**. This process of unwinding the **Stack** and the **Heap** until the **Exception** is caught by an [[dido:public:ra:xapend:xapend.a_glossary:e:exception_handler]] programmed to handle the particular kind of error thrown. If an **Exception Handler** is encountered that does not handle the error, the exception is rethrown until an **Exception Handler** is found that does handle the error or the program **Stack** is empty (nothing left to pop), which terminates the program and control reverts to the [[dido:public:ra:xapend:xapend.a_glossary:o:os]]. |
| **Exception Handlers** can be quite specific in which **Exceptions** they can handle, or they can be very generic. | **Exception Handlers** can be quite specific in which **Exceptions** they can handle, or they can be very generic. | ||
| - | To catch specific **Exceptions** that can arise from a method, many OO languages allow for a method to declare what known exceptions can be thrown from the method. For example, if a method allocates memory from the **Heap**, it may need to indicate it can throw an **'' Out of Memory''** exception. The following example of a writeMessage routing demonstrates how a method can inform a caller of the potential exceptions it can throw (i.e., **''IOEception''**). | + | To catch specific **Exceptions** that can arise from a method, many OO languages allow for a method to declare what known exceptions can be thrown from the method. For example, if a method allocates memory from the **Heap**, it may need to indicate it can throw an **'' Out of Memory''** exception. The following example of a **''writeMessage''** routing demonstrates how a method can inform a caller of the potential exceptions it can throw (i.e., **''IOEception''**). |
| <code java> | <code java> | ||
| Line 62: | Line 62: | ||
| - | To generically catch all **Exceptions** in most OO languages, using a simple **''Catch (Exception e)''** block within the **Exception Handler** is all it takes. It is considered good a programming practice to do this at most component, subsystem or system boundaries and to log these conditions for later review. These log entries also usually include a **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_trace]]**, which in simple terms is a list of the method calls that the application was in the middle of when an Exception was thrown.(( | + | To generically catch all **Exceptions** in most OO languages, using a simple **''Catch (Exception e)''** block within the **Exception Handler** is all it takes. It is considered good programming practice to do this at most component, subsystem, or system boundaries and to log these conditions for later review. These log entries also usually include a **[[dido:public:ra:xapend:xapend.a_glossary:s:stack_trace]]**, which in simple terms is a list of the method calls that the application was in the middle of when an Exception was thrown. (( |
| Stackoverflow, | Stackoverflow, | ||
| __What is a stack trace, and how can I use it to debug my application errors?__, | __What is a stack trace, and how can I use it to debug my application errors?__, | ||
| Line 101: | Line 101: | ||
| ===== DIDO Specifics ===== | ===== DIDO Specifics ===== | ||
| - | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers | Return to Top]] | + | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:start| Return to Top]] |
| An interesting phenomenon about many of the [[dido:public:ra:1.2_views:1_stakeholder:1_platform | DIDO Platforms]], is the way they treat **Operation Data**. Many of the [[dido:public:ra:xapend:xapend.a_glossary:p:platform | Platforms]] not only distribute **Field Data** using **[[dido:public:ra:xapend:xapend.a_glossary:d:distributed_ledgers]]** or **[[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:3_xdata:1_jrnl | Journal]]**, they also distribute the **Operation Data** in the same way (in essence, treating the software just as any other data). When changes are made to the **Operation Data**, a **[[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:2_ido:2_trans | Transaction]]** is created to be pushed to the **[[dido:public:ra:xapend:xapend.a_glossary:n:node_network]]**. | An interesting phenomenon about many of the [[dido:public:ra:1.2_views:1_stakeholder:1_platform | DIDO Platforms]], is the way they treat **Operation Data**. Many of the [[dido:public:ra:xapend:xapend.a_glossary:p:platform | Platforms]] not only distribute **Field Data** using **[[dido:public:ra:xapend:xapend.a_glossary:d:distributed_ledgers]]** or **[[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:3_xdata:1_jrnl | Journal]]**, they also distribute the **Operation Data** in the same way (in essence, treating the software just as any other data). When changes are made to the **Operation Data**, a **[[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:2_ido:2_trans | Transaction]]** is created to be pushed to the **[[dido:public:ra:xapend:xapend.a_glossary:n:node_network]]**. | ||
| Line 111: | Line 111: | ||
| * [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:07_special]] | * [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:07_special]] | ||
| * [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:09_general]] | * [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:09_general]] | ||
| + | * [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers:11_visibility]] | ||
| - | + | <color blue><todo @char #char:2022-03-22>Review </todo></color> | |
| - | + | ||
| - | ===== General Methods ===== | + | |
| - | [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:07_opers | Return to Top]] | + | |
| - | + | ||
| - | <color blue><todo @char>New Section -- review </todo></color> | + | |
| /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ||