The most important structure in the application of exceptions – Try, Catch, Finally The following is the structure of the block. What is important in the case of the application? The point is that all types of exceptions that will apply, and what will be higher in the list of catch blocks were the most nested within each other. You can say yes, all can inherit from Type1 Type2, but the phenomenon is never the other way around. In practice it is so that each block acts as a so-called catch and filter for all exceptions. Example 1 – The design of the Try, Catch, finally TryCatchFinallyExample {public class tryCatchFinallyExample {public void try { / / Code that may cause an exception } catch (Type1 ex1) { / / Exception handling code named Type1 } catch (Type2 ex2) { / / Exception handling code of type Type2 } finally { / / Code that is executed whenever / / Regardless of exceptions } } } Below I will present to you one more thing. It will be a difference that occurs when re-throwing the exception. TryCatchFinallyExampleTwo {public class tryCatchFinallyExampleTwo {public void try { / / Code that may cause an exception } catch (Type1 ex1) { / / Log the exception and re-throw / / Retain our original Call Stack – Ok throw; } catch (Type2 ex2) { / / Logging, container and cast – Ok throw new TYPE5 (ex2); } catch (Type3 ex3) { / / Logging and loss of information / / The thrown exception throw new Type3 (); } catch (TYPE5 ex3) { / / Login and complete loss of information / / The call stack exception source throw ex3; } finally { / / Code that is executed whenever / / Regardless of exceptions } } } How do we log exceptions? Login exceptions are a very complicated process. Their main objective is to send a notification to the object that a certain type of event occurred. To what object we can save the event? Practically, it can be any object with which we are dealing. This may be as good as the console, or a file on the disk or database. Might as well be the object of a remote computer. In a world in which we live are all key login information. This could be information for the developer on how to implement the program. Logs are also exceptions that occur when you run the program. Very often logs are also subject to system events and user actions. To log exceptions, frameworks are primarily used. They are nothing more than a programming platform, which really serves as a framework for building applications. A framework application usually defines the structure and defines the general mechanisms of action, and some elements of the behavior of the application. The framework also provides a set of components and general purpose libraries that can be used to build any application. To create this type of application, the programmer can only expand and implement individual components to the requirements of the project. It is in this way creates the majority of packaged applications. When you create each application you usually have several options that you can use. Mostly you can always go in the direction of the three types of solutions to problems. Here they are: We can write the code for the entire application logging. This is very time consuming, hardly inflexible and difficult to maintain. It is also very prone to errors. A much better solution, only a little less time-consuming, but cheaper to maintain is to write your own logging framework certain events. Several times I had to write my own framework or wrapper and I admit that when they were created I really learned a lot. The last of the possible solutions is to use a high-quality framework, written by the entire development team. I highly recommend this solution, but I have one little point to call to attention. If we are not able to master a framework within two hours, and I do not mean perfect mastery, but about hearing the basic functionalities, let us abandon the idea of its use and choose something else. If we as developers we do not understand the rules of something quickly, the client certainly does not understand the same principles of operation. Why not log exceptions? It often creates large business applications that take advantage of a huge amount of third-party libraries. Whether you are working with visual applications, and communication and computing, it is the most important source of information about problems that may occur. In fact, each application may crash without giving any reason. It is then that it is impossible to find a problem without a thorough analysis of the logs. Always the first thing every programmer should do when writing software should be correct logging mechanisms to implement exceptions. After trying many different solutions, I personally use log4net library dla.języka C # and log4j when I write a Java-based solution. Below is the log level of the library, categorized in descending order:

Off – turns off logging errors

Fatal – shows only critical errors that cause premature termination of the application

Error – runtime errors

Warn – all kinds of warnings that indicate, for example, to use an old, outdated API

Info – all the information about certain events, such as opening or closing applications

Debug – detailed information about the application or system

Trace – all the detailed information that is useful to any developer

Sometimes it is used to set a minimum level of logging called Error, which will only display errors or Fatal Error type, but now avoids errors like Warn. In the case of libraries log4 it is also possible to set the exact scope of any such communications.

Recent guidance on the use of exceptions

At the end of our discussion on exceptions, I would like to introduce you to recent guidelines for their use. I managed to collect all of them as a logical whole. Here they are:

You have to remember that the principle that exception handling is really error handling. It allows for a clear separation of code and code to plain error handling.

Never use exceptions anywhere where there are adequate local control structures.

Do not use exceptions to control applications regularly. Always a much better option is to check all types of conditions for entry into the method just before the execution of the exception than the accused.

Note that not every function must handle every possible error.

You always have to assume that if the function is able to report any exceptions, it certainly will.

The library can not unilaterally from itself disrupt any of the programs. Instead of using such a solution, report an exception and allow the caller to make such decisions.

Please note that all error handling strategies are planned at a very early stage of the planning of the application.

Always report all critical errors by throwing exceptions. Follow this mechanism when the method can not perform these operations in terms of which it was created. Let it then be regarded as a very significant error and throw an exception. Never use for this purpose codes.

I always throw the most specific and most inherited exceptions. If Null is much better to throw ArgumentNullException, ArgumentException will be the exception rather than the base. For your own code, always try to create your own exceptions.

In any case, the code in the catch block can never throw random exceptions.

Do not throw any exception explicitly, which is located in the finally block.

Try not to catch any of the specific exceptions to the general Exception class for any purpose other than to log the error and throw them away.

Always arm only those exceptions, which you know how they react.

A good example:

GoodExceptionExample {public class public static void main (String args []) { try { … } catch (SystemArgumentOutOfRangeException exc) { … } catch (SystemInvalidCastException exc) { .. } } } Very bad example:

GoodExceptionExample {public class public static void main (String args []) { try { … } catch (Exception exc) { … } } } If you can try to use the same word throw, for catching and subsequently throw an exception. This behavior allows you to keep the Call Stack.

Always use a try-finally to release resources:

GoodExceptionExample {public class public static void main (String args []) { FileStream stream = null; try { stream = new FileStream (…); … } finally { if (stream! = null) { stream.Close (); } } } or its equivalent in C #:

using (FileStream stream = new FileStream ()) { } Another very common mistake is to catch only exceptions so that none of them do not catch. In many cases, the exception is logged only lead to a problem that really occurred.

Always show the user some information about what happened. Forward it as a very communicative information, and all the details of the exception log.

Whenever you work with any external systems, such as network file systems, device or files, always add application support for exceptions.

Always consider the use of AOP (Aspect Oriented Programming) when handling all standard errors.

Capture exceptions only if you are planning one of the following actions: restoring the system, the release of resources, event registration, generation of diagnostic information.

Never intercepts and base types do not generate exceptions. Login Exception class does not really make much sense.

Use exceptions only to handle unexpected events. Never use them to implement the entire application logic.

Summary

In these two articles we met the concept of exception. As you can see this is a very complex concept, and very difficult to understand. I myself at the beginning did not understand why there are exceptions and why to use them.

Exceptions are really very useful for writing high-quality software. As an example, I’d like to mention one very important thing. In the articles devoted to software testing, I wrote that some stocks and some things may be intentional or deliberate. Sometimes they even deliberately initiate such a thing as a mistake, to see how your application will behave under certain conditions. Note that such an action can always wrap the clause try .. catch .. finally and calmly print the information about what is happening in the system. If you properly apply the exceptions to expedite the process of software testing, and time is money. So it has always been.

Exceptions also have another definite advantage. Nothing annoys users like applications that come to an end and throw some weird message that is really quite incomprehensible to them. And here also comes with exceptions, because every exception we can pass on, and you also provide information about what really could go wrong, instead of some incomprehensible share programming.

Additionally, with the exceptions I have to mention one thing. Well, I used to use Windows and the blue screens did not annoy me. Then, Windows XP would appear with some error message in the kernel of the operating system, which was also my very readable. I think a more elegant solution that would settle in a way that I, as a user, get clear, is a short message about what could have happened or what I did wrong, and to provide information about what really happened to the rest of the system, or in extreme cases sending it over the network quietly to Microsoft, to help them create systems so as to be the best for us, the end users.

As you can see, really good software production process is not an easy process. What we learned today is really just the beginning of your journey to this to create a beautiful, easy to read and easy to maintain code. In the next article in this series I will introduce you to all the main principles of using external libraries, and write about how they attach to the software. Then we will return for a moment to multilayer architectures, because I want to show this issue in a few examples, and then I will write about programming that we can use when writing software.

Recent guidance on the use of exceptions At the end of our discussion on exceptions, I would like to introduce you to recent guidelines for their use. I managed to collect all of them as a logical whole. Here they are: public static void main (String args []) { try { … } catch (SystemArgumentOutOfRangeException exc) { … } catch (SystemInvalidCastException exc) { .. } } } Very bad example: GoodExceptionExample {public class public static void main (String args []) { try { … } catch (Exception exc) { … } } } public static void main (String args []) { FileStream stream = null; try { stream = new FileStream (…); … } finally { if (stream! = null) { stream.Close (); } } } or its equivalent in C #: using (FileStream stream = new FileStream ()) { } In these two articles we met the concept of exception. As you can see this is a very complex concept, and very difficult to understand. I myself at the beginning did not understand why there are exceptions and why to use them. Exceptions are really very useful for writing high-quality software. As an example, I’d like to mention one very important thing. In the articles devoted to software testing, I wrote that some stocks and some things may be intentional or deliberate. Sometimes they even deliberately initiate such a thing as a mistake, to see how your application will behave under certain conditions. Note that such an action can always wrap the clause try .. catch .. finally and calmly print the information about what is happening in the system. If you properly apply the exceptions to expedite the process of software testing, and time is money. So it has always been. Exceptions also have another definite advantage. Nothing annoys users like applications that come to an end and throw some weird message that is really quite incomprehensible to them. And here also comes with exceptions, because every exception we can pass on, and you also provide information about what really could go wrong, instead of some incomprehensible share programming. Additionally, with the exceptions I have to mention one thing. Well, I used to use Windows and the blue screens did not annoy me. Then, Windows XP would appear with some error message in the kernel of the operating system, which was also my very readable. I think a more elegant solution that would settle in a way that I, as a user, get clear, is a short message about what could have happened or what I did wrong, and to provide information about what really happened to the rest of the system, or in extreme cases sending it over the network quietly to Microsoft, to help them create systems so as to be the best for us, the end users. As you can see, really good software production process is not an easy process. What we learned today is really just the beginning of your journey to this to create a beautiful, easy to read and easy to maintain code. In the next article in this series I will introduce you to all the main principles of using external libraries, and write about how they attach to the software. Then we will return for a moment to multilayer architectures, because I want to show this issue in a few examples, and then I will write about programming that we can use when writing software.