Objectives of Implementing an Exception Handling Mechanism
I know from wikipedia, for example, that exception handling is used in an application to custom handle certain errors in fail-safe mode. However, I'm not sure why, in these cases, the developer would want the user to experience the error as reset in fail-safe mode. Below is the pseudocode of what I am doing (but I am not sure what the biggest purpose of the exception is in this case).
while(not exitting the program)
{
try
{
Perform(); // perform custom calculation by calling
}
catch(int e)
{
sort out what e stands for
reset the variables of the object
}
catch(...)
{
print message
reset the variables of the object
}
}
It would be great to hear some comments. Thanks in advance.
source to share
The idea of exception handling is not to suppress errors, but to create the best out of a bad situation.
Take a minimalist browser app, for example. And let's say that you are trying to open a web page from a server that is currently unavailable.
At the lowest level, you can get a socket exception as the remote server is not accepting any connection (depending on the structure). You now have essentially two options:
- Let the browser application die along with the generic error message provided by the operating system.
- Handle the error and do your best: show the error page and enable the redo button.
In a sense, the error is actually ignored, but it is also not allowed to crash the application.
The browser example is a typical situation: you have a low-level error, but you just don't let it crash your application. Instead, your application can restore it and possibly provide alternative actions.
source to share
Exception handling is generally considered much better than alternatives.
i.e. ignoring errors or checking return codes.
Generally speaking, there are three (or four) things you can do when you catch a mistake.
1 - handle / ignore it. If you decide that the exception does not prevent your program from running correctly, this is the correct action. eg Exceptions for file type exclusion.
2 - Try an alternative. for example, if "file not found", create a new file containing the defaults and open it.
3 - Broadcast the technical error into a user-understandable error and notify the user. eg instread of line 30 com.java.jdbc SQL exception ... message You are informing the user "No pricing information for the requested product code"
4 - Only in the Java world - and everyone doesn't like it - pass the exception through the calling process.
The number 4 is especially annoying because one of the main advantages of exception handling from a programming style point of view is separating the erroneous error handling code from the "real" one, which makes your business logic, the tedious process of declaring, trapping, and throwing exceptions that you don't want to handle. your code leads to a lot of distracting clutter in your average Java program.
source to share
Exception handling doesn't really have anything to do with the user, it's about decoupling error handling logic from "normal" logic. Languages like C ++ and Java have constructs like:
try {
makeDough();
bakeBread();
eatIt();
}
catch(RecipeNotFollowed error) {
tellSomeoneToThrowTheDoughOutAndStartOver();
}
catch(OvenNotOn error) {
tellSomeoneToTurnTheOvenOn();
}
This section try
is for "normal" logic. Section catch
for handling errors. They differentiate between two types of logic and simplify error handling. Consider an alternative with error codes:
boolean doughMadeCorrectly = makeDough();
if(!doughMadeCorrectly) {
tellSomeoneToThrowTheDoughOutAndStartOver();
return false;
}
boolean breadHotAndCrispy = bakeBread();
if(!breadHotAndCrispy) {
tellSomeoneToTurnTheOvenOn();
return false;
}
eatIt();
return true;
Slightly silly example, but I think it shows big differences between the two main ways of handling errors. One way is that the two types of logic are grouped together, otherwise they are interspersed. I find the exception handling is much cleaner.
source to share