Classical Error Handling

I've always loved how programming languages provide many (elaborate) ways to handle errors in your programs. When I first started with C language, intro(2), perror and strerror were the functions I used the most to output sensible error messages in my log files. I'd say in a program you've written, using perror(argv[0]) makes a ton of sense since it lets you know which file exactly had the error in it with messages defined in the header errno.h

Object oriented languages support exception handlers and they to me add much more value than classical error handling. Imagine, for each function call you make you'd have to handle the error values returned by the function - on the spot. Exceptions allow you to have fine-grained control over the flow of the program. An instance of exceptions would be - say if you read an element past the upper-bound of the array. You'd get a corresponding exception; to use the in-built exception handler or defining your own bunch of statements will depend on the programmer. Usually the exceptions are handled after your main code has been written in a block of code, ensuring that they have their own place in your code.

If you trace how this idea took shape, you'd find yourself reading "Exception handling for C++ (revised)" by Stroustrup, and Koenig. Many high-level languages like Java and C# have benefited from this idea and continue to add useful features.

As of now, I haven't played too much with interpreted languages like perl and python, but it will be exciting to see how error handling is supported by them.

No comments: