Run time errors can happen to any single line of code, regardless of the syntax, semantics, and logic.
Nobody can assure that an application can always run properly, due to many reasons, and the most important ones are the externals, I mean the machine, the OS, the network, and even the user that will interact with the application.
As discussed, regardless of anything, run time errors are very possible, but the effects, severity, frequency, and occurance of this sort of errors are still manageable by exception handlers.
Exception handling is basically the process of responding to an exception occurrence, during computation. An example of an exception, is navigation to a form or page that no longer exists, and a possible handler is a nice page or form, designed for this purpose, informs the user about what went wrong with an option to report the error and exit, or navigate to an elsewhere within the application.
It is so good to consider having an exception handler for each and every code snippet developed. And, it is much better to have a specific handlers, beside the generic ones. This would definitly improve the effeciency, reliability, and compatibility of an application.
The below are good examples of what exception handlers throw in case something strange just happened. I'm sure you can recall similar ones popped up in the middle of your screen, at a point of time, by an application or an OS.
The below is an example of a specific error handler, in case of navigation to a page which does not exist:
And here is an example of a general handler:
Finally, what are the potential concequences of an unhandled error?
A perfect answer of this question is never there, because there are endless potential scenarios that can lead to endless possible reactions by the application, database, OS, or other involved components.
A common response by an application or an OS to an unhandled exception is getting stuck, or stopping to respond. How bad this can be, especially in a production server. Other things which are indeed worst are still possible, like a complete system crash. The minimal impact of an unhandled exception is getting a message from the OS error handling component, similar to the below one:
Remember, exception handler is a master key of an effecient, reliable, and compatible application. Moreover, it is ALWAYS needed.
Peace!
Nobody can assure that an application can always run properly, due to many reasons, and the most important ones are the externals, I mean the machine, the OS, the network, and even the user that will interact with the application.
As discussed, regardless of anything, run time errors are very possible, but the effects, severity, frequency, and occurance of this sort of errors are still manageable by exception handlers.
Exception handling is basically the process of responding to an exception occurrence, during computation. An example of an exception, is navigation to a form or page that no longer exists, and a possible handler is a nice page or form, designed for this purpose, informs the user about what went wrong with an option to report the error and exit, or navigate to an elsewhere within the application.
It is so good to consider having an exception handler for each and every code snippet developed. And, it is much better to have a specific handlers, beside the generic ones. This would definitly improve the effeciency, reliability, and compatibility of an application.
The below are good examples of what exception handlers throw in case something strange just happened. I'm sure you can recall similar ones popped up in the middle of your screen, at a point of time, by an application or an OS.
The below is an example of a specific error handler, in case of navigation to a page which does not exist:
And here is an example of a general handler:
Finally, what are the potential concequences of an unhandled error?
A perfect answer of this question is never there, because there are endless potential scenarios that can lead to endless possible reactions by the application, database, OS, or other involved components.
A common response by an application or an OS to an unhandled exception is getting stuck, or stopping to respond. How bad this can be, especially in a production server. Other things which are indeed worst are still possible, like a complete system crash. The minimal impact of an unhandled exception is getting a message from the OS error handling component, similar to the below one:
Remember, exception handler is a master key of an effecient, reliable, and compatible application. Moreover, it is ALWAYS needed.
Peace!
No comments:
Post a Comment