قالب وردپرس درنا توس
Home / Tips and Tricks / What is the difference? – CloudSavvy IT

What is the difference? – CloudSavvy IT



Glitch hazard symbol
Shutterstock / SkillUp

Computer problems. We all have them sooner or later. Knowing the ins and outs of errors, claims, crashes and more is vital to learn more about the issue in question. Learn all about it.

What is a claim?

When a developer starts writing code, they will introduce soon if statements therein. A if statement is used when a certain condition needs to be tested. For example, one could write a pseudo-code if statement as follows:

if (water_level > high_water_mark) then {
  raise_alert
}

In other words, if the water level rises above the high mark, an alarm is raised. But maybe the water sensor is broken, so we update the code to match:

if (sensor_readout == nonsensical) then {
  raise_error
  fail
}else{
  if (water_level > high_water_mark) then {
    raise_alert
  }
}

Great, now we get an error and the routine will fail if the sensor_readout is nonsensical. And only if the value turns out to make sense (because of the else clause—that is, what to do in the opposite situation), proceed to check the water_level against the high_water_mark.

However, someone may have turned off the power to the sensor. We could go on like this for a while. We can cover every conceivable scenario and still miss a few. Of course we can cover every possible situation with a matching else clause and check if each condition is compared to another, but even in such cases we may have missed some combinations of variables.

Even if we only had a limited set of variables to work with, the number of possible combinations a software package can be in is quite numerous. And what̵

7;s more, this kind if conditional tests are quite common in almost all software.

If we reason a little further about this dilemma, we quickly understand that we (as developers) (like all humans make mistakes) can sooner or later introduce code that allows the software to break into undefined territory. Variable x is set to a specific value, variable y is assigned to another, and there was no provision for this in the code.

This is exactly the situation that an assertion can provide to some extent. A statement is another condition (think about it like another) if statement.) that claims whether some strange/unusual/unplanned/unforeseen situation exists and usually handles such situation by quitting the program rather than continuing with an undefined/unknown condition.

While the net that the asset test will deliver is still limited to the intelligence and skills of the developer implementing the assertion, an assertion can often be made wider than the limited confines of if statements that test the state of different variables, or it can be made very specific to avoid certain dangerous situations.

For example, let’s say our little water sensor is mounted in a rain tank. The water should therefore never boil. However, if our water sensor had a temperature gauge, we could be sure of it, even if it never would/shouldn’t happen. Let’s add a statement to the pseudo code we started above.

Instead of the boiling point (100 degrees Celsius), we are going to look at a more reasonable maximum of 70 degrees Celsius, which in our opinion should never be reached if we think about collecting rainwater. Remember the word “opinion” as this becomes important when considering the cleverness of the developer implementing the claim. (More on this below.)

if (sensor_readout == nonsensical) then {
  raise_error
  fail
}else{
  assert (water_temp < 70.0){ 
    raise_assert_message 
    fail 
    exit 
  } 
  if (water_level > high_water_mark) then {
    raise_alert
  }
}

We wrote the statement in reverse order. The code must confirm that the water temperature is below 70 degrees Celsius. If not, it will execute the block of code, which will prompt a confirmation message, then the software will fail and shut down.

Claims in the actual code are very similar to the example above. They test whether a particular situation applies or not, and then stop (or crash in a controlled manner) the respective program/software.

Often these resources are logged in the application logs or even directly on the screen output. Viewing them and/or searching for a copy of the exact message in your favorite search engine will often (if the bug has been found before) lead to a bug report about it.

Assert messages are often bugs, although they may just be bugs in the developer’s reasoning. After all, who says that in 1000 years the rain might not be hotter than 70 degrees Celsius? (But let’s hope not!)

An assert message is the output represented by the assert introduced into the code by developers, ie the actual text output generated by the software and displayed on the screen or in the logs. For example, imagine that this message is shown for the above program.

Assert: (water_temp < 70): (88 < 70): false

While it looks a bit cryptic (as some of the claims are), we realize that in the second part, if we look a little closer, water_temp was exchanged by 88 and that the output is false (ie the assert water_temp < 70 failed because the water was 88 degrees, so the assert triggered the assert message). Yes, it can be a little confusing.

Armed with these new skills, debugging an assert message will be a lot easier the next time you see one. You may also find it easier to understand exactly what went wrong when the application was stopped.

What is a Wrong?

Errors in computer science happen all the time and for a myriad of different reasons. They happen at both the developer and user level and at every step in between. For example, a DevOps engineer might forget to include a necessary file, or a package signer might use the wrong key to sign the software, and so on.

Basically, a computer error can be defined as a problem with computer hardware or software. There are some examples of an error even in the limited pseudo code above. When the sensor_readout == nonsensical condition is met, an error message is displayed.

There are certain mistakes that are more common than others. For example, using a wrong path or wrong file name is a common mistake. Power-related issues (e.g. low battery) are also common errors.

Errors are quite distinct from and distinct from assert messages, even though the assert message in itself can be seen as an error, or rather, as an undefined situation now covered by the assert message. In general, a computer error usually translates well to "I need a human to fix this".

Hopefully, as computers become more intelligent and AI evolves, fewer errors will be produced, although there is still a lot of room for discussion and even argument in that area.

What is a? Crash?

A computer crash can take many forms. We are all familiar with the Microsoft Windows blue screens, which tended to happen when an application misbehaved or a core component of the machine's operating system or hardware would fail.

Most of the time, however, a crash is a software application that got into an undefined situation. Many such undefined scenarios are possible. A computer may have tried to write to an area of ​​RAM that is already in use, which upset itself or some other application, or it may have entered a scenario where it tried to divide by zero (which is impossible), or a similar situation.

Many operating systems will write a core dump file (if configured), which allows a developer and sometimes an end user with some skill to solve the problem.

If you want to learn more about debugging when things go wrong, including analyzing core dump files, you'll probably find our article Debugging with GDB: Getting Started interesting.

A crash can also be the result of an application entering an undefined situation, which is not handled by an error (the lightest way for an application to inform you that something is wrong) or an assertion (a deeper issue, originally excluded by the developer as impossible, but still occurs).

Also keep in mind that a program built for testing, i.e. with debug information (including debug-level assertions only) embedded in the final binary, may crash when it produces an assertion, as is the case with the MySQL server for example .

Shut down

In this article, we explored the concepts of assertions, errors, and crashes, as well as how they relate. We took an in-depth look at what assertions in the code might look like and how this compares to a real-life example of monitoring water level and temperature with a water sensor. The next time you come across a confirmation message, take a closer look and enjoy debugging!


Source link