Re: Try/Catch
- Posted by Shian_Lee Jan 07, 2015
- 5775 views
Please explain me briefly, using simple words, why exception handling became norm in computer programming.
The obvious example is the web browser. Imagine, say, amazon.com: there is text in various fonts, colours and sizes, lines, icons, pictures, zoom-able pictures, videos, bar charts, bullet points, shrinking and expanding sections, hyperlinks, buttons, etc. Other sites have word documents, pdfs, powerpoint presentations, excel spreadsheets, and so on, all of which can be displayed directly in the browser. You can also add client-side javascript, html5, css and more of the like to the bucket. That is a lot of things that you and I have no control over, that can go wrong in a multitude of different ways.
In my own programs, I almost always use long-handed and tedious error code (aka return value) handling. But I have to accept there is a real and imperfect world out there.
Pete
This doesn't actually answer the question. The analogy is a very good one (showing why/how popular things are not necessary the best way), but not how they became popular in the first place.
To directly answer the question, exception handling became more common because, from the end-user's point of view, it's easier.
It is a lot easier for a novice programmer to come up with a functional program, without having to deal with the complexities of properly handling errors, by abusing try/catch.
That said, I think try/catch does have its place, just like goto. But also like goto, it can be abused. At some point though, it becomes counter-productive to protect other people's feet from their own shooters.
Thank you.
These answers are really ambiguous for me. Honestly, I don't feel that I got an answer at all.
Once I've programmed a PLC with maybe hundreds of INPUTs and OUTPUTs. That PLC controlled many engines, sensors, and machines with huge power, in the tyres industry.
In these machines, something goes wrong almost all the time. Also, these machines are depending on each other's proper operation, in a similar way to a web browser.
Since PLC works in a very logical way, I found it very simple to write the program; I just needed time. Most decisions in a PLC program are taken only based on Boolean flags, which makes the program very clear.
I don't know why computer program has to break its own logic and fall into a dangerous game of throw and catch. In more critical programs, such as PLC programs, this considered to be the most non-robust behaviour.
Programming a PLC is different then programming computer, in a way that the program must work; and if it doesn't: you call the programmer back to finish his work. Machines don't understand bugs, and improper behaviour of machine can cause a big accident.
Pete gives an example of x = y[z]. Out-of-bound and not initialise variables happen anyway, with or without exception handler. This is the main difference between PLC programming and computer programming; In PLC programming the programmer must take responsibility for his mistakes ("bugs"), while in computer programming bugs are part of any program.
I used error handling in QuickBasic many times before, because QuickBasic don't supply returned error codes - it simply crashes.
Using error handlers in QuickBasic was the worst experience from that language. And at those days QuickBasic worked on DOS(!).
Fatal error such as "Illegal function call" is a bug that I, the programmer must fix - not a pathetic error handler that sends the user back to the main menu after two hours of hard work.
Fatal error such as "Drive-not-Ready" are the most ridiculous; Drive not ready - so what??? In PLC programming if a digital sensor tells me that the tank is not empty then my program simply waits until the timer stops, and then turns on a red light on the control panel. that's it. simple.
Computer is a machine. And it may be connected to other machines. Checksums, error codes, and branching statements are much more solid and robust programming behaviour, for truly critical operations. That's why there is no "fatal error" in PLC, since PLC should never stop its operation. There might be an adjustable watchdog that continuously test the proper operation of the PLC (similar to computer BIOS chip), and stops the PLC in case of improper operation - but PLCs are built to be reliable and robust.
From my personal experience error handler is the hardest to write and the most fragile programming method. It also forces the programmer to use it - as in QuickBasic - even if he really wishes to avoid it.
I really don't understand the answers since my experience proves the opposite...
