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.

Differences in languages.

With the wealth of features C++ offers over C, it's important to note the various ways in which their features are different. For instance, a string literal in C++ isn't the same as the string datatype. Also, C-style strings are different than both!

Code:
string s1;
string s2 = "I am a string";
char str[20] = "I am a string";

I've only listed one amongst hundreds of nuances. I think it's more of a personal choice to dive deep into a language and fish out interesting notes of these types. When I'm done with these two languages, I'll have to post my opinions - in detail.

First opinion

Since this is my first post, I thought it best to write about the nature of my blog. I believe that its neat to be passionate about software. There are many blogs, websites and books I read on a daily basis, to improve my understanding of software and its various forms.

I am presently combining the features of FLTK with LAM-MPI, to develop an application to visualize 3D data. It's been fun-filled for the most part, as I get to speak with many experienced users of both libraries on their respective mailing lists. From what I've learnt so far, there isn't only one way to implement a particular feature. So for today, I'd like to close by saying -- whenever you'd like to solve a problem, think for alternative ways to solve/implement it. This practice always comes in handy in the face of tough problems, that demand a bit of lateral thought.