I have corrected one of my shell scripts and succeeded to get it running again.

This is okay.

But the time it took me to

1. understand that the reported errors weren't errors
2. understand that the called program had no bug (other than the missing exception-handling)
3. understand that the error was my own
4. understand my error
5. to correct the error

is NOT okay.

Question (Rant): What part of Exception-handling do you consider optional?

I always like to recall the OutOfMemory errors in Apache-Tomcat, where the Error was caught and the handling was done by
(full code extract).

Aren't there any laws against such laxity?

Personally – believe it or not – I consider it my responsibility to react as a developer! Else, why did I start to program anything in the first place? Control-structures (if) exist and while I am at it, why not use them?

Thanks for reading.

I don't really understand this, but I do think out-of-memory shouldn't be handled at all (other than writing error-message and/or creating core-dump before terminating the program).

This is the right way to think. With the {}, they achieved that a Web-application just crashed at an arbitrary point in time with an arbitrary error being raised and no way to deduce the OutOfMemory situation. “We automatically restart Tomcat once each day and got rid of the problem” was the accepted remedy and: “If you want our high-quality software you will have to install bigger servers, it is like that.”

Back on-topic:

I collected a bunch of Name-Errors and uninitialized variables from a program which parses a command-line and then executes it. That the command-line was ill-composed had not been obvious to me and the program in question is not prepared to tell me.

But this is not the first time and not the only program concerned.

Out-of-memory is becoming obsolete. It was fairly easy to exhaust a 32-bit address space. A 64-bit address space is not likely to be exhausted. Instead, the program will slow to a crawl.

Programmers have to be careful to validate the input (always!). Nearly all security holes are caused by a lack of validation of the program's input.
Ed

Though the swap-space isn't infinite either.

tomcat if I remember correctly is a java thing... Java if I remember correctly, hey it's been awhile since I used java... you have to tell the java runtime how much memory is available to it and it won't grow beyond that. So that's sort of orthogonal to the kernel and swap and the OOMkiller view of the world.

The "gotcha" with any OOM situation and handling it... is (especially in something like Java) it can hit you just about anywhere since Java allocates objects all over the place.

So that means you can't be sure of the state of anything when it hits.

That means 99% of the facilities you may wish to use to handle the problem....(eg. tell the web site user he is trying to do something too big) are possibly in an invalid state that will cause crazy buggy things to happen if you try.

It also means that 99% of the things you may wish to do to handle it... eg. print a sensible message.. will attempt to allocate more memory..... which doesn't exist...

Around about the best you can do is (if you're lucky) is dump a stack trace and die, which will hopefully point at an allocation which will tell you what the problem is.

ie. You need to be taking sensible actions before you hit OOM. Trying to do something when you hit OOM is too late.

I am encountering the same kind of problem with programs and code written in C/C++ and Ruby. Probably others but I have not cared to dig into each of the programs concerned:

People use software in their own projects, either as a library which is linked or otherwise included (in case of interpreted languages), then appear to believe that:

It is the task of the end-user to interpret the information that the developer of the *used* code chose to communicate to the *developper* of the later program in order to improve the quality of a future, yet unknown, code.

Well. It is not.

Almost all exceptions are part of the development process and not of the use of a somewhat “final” project.

Call this thread “the current state of IT”, if my Tomcat-example is too diverting.

I was promenading behind two university-students, one of both praising the merits of Java-Exceptions, to which the other responded that (I cannot remember the exact wording) if, while and switches were sufficient to him to achieve the same.
What I believe to have understood was that the first used Exceptions as a replacement for “Goto” which he had probably been taught to avoid.

nowadays we used to generate two different logs, one for the end user, which just reports what's going on, what went wrong, reports errors, and the other one for the developers containing all the technical info (including stack traces and debug info).

Exact. This is just one possible hierarchy, put the end-user where you want. All depends on what you put into the logs.
------------------
log.error (, log.fatal)

⇓

log.warn, log.debug

⇓

log.info
------------------
Edit: What's wrong with:

• “Cannot interpret your program arguments”
• “Program cannot procede due to an unexpected event”
• only then – and if you want – tell the user to transmit the following stack-trace.

... because you had not had the opportunity to handle an exception, but you will now.