The one variant I think can be useful involves an opaque abstraction, which defines a set of its own exceptions, framed solely in terms of that abstraction. Any opaque abstraction is violated when an unanticipated implementation failure occurs, as it cannot be framed in terms of the abstraction. The best the abstraction can offer is a "weasel words" exception that chains the original cause, shamefully "exposing its call stack to all the world". Recovery code can log the cause for the support ticket. The posted code, of course, is simply gross. It adds nothing, hides nothing, and loses everything that might be of support value, while working hard at looking lazy. Doing nothing would be far lazier and far more effective.

On the one hand, it's good to continually look for ways to code elegantly in the place you find yourself. On the other hand, there's no shame in keeping it simple and programming in a way that is mutually recognizable across a number of languages. If the language-neutral version is hard to understand and you learn a better way in the language, just refactor it. Changing to something simpler and smaller is generally safer than the long slow trudge in the other direction that any code base tends to make over the years. :) I never saw much point in someone saying "I'm a C# developer" or "I'm a Java developer" or "I'm a C++ developer", like a single platform was a career or something. A successful career will outlive anything specific we know. The real deal is in a deep understanding of the patterns of design and usage that apply across platforms and being curious enough to learn what you would use to express them on several common ones and at least one emerging one.

I once programmed in a language that was limited to six-character names in the symbol table. I don't do that anymore. I once programmed in a language where variables were conventionally a single character, maybe with some digits. I don't do that anymore. I once programmed in a language where all variable names that weren't parameters were global to the program. I don't do that anymore. In fact I haven't done any of these things since the mid-80s. Names need to be descriptive and use words - noun phrases. Names can be contextual on method, class, and namespace and not use big noun phrases. If you need a really big name to distinguish items, your current context has become crowded. Refactor something, then continue with short names made unambiguous by context - just like we do in outside life.

I've started using it and as long as the IDE makes it easy to do my usual development cycle without paying attention to the tool, the lack of color isn't a turn-off. A good IDE is like a good butler, functionally invisible but its absence would be sorely missed because you'd have to start attending the minutia of living yourself. Having used VS2010 with all its gazillion enigmatic buttons for two years, VS11 seems a lot less "noisy", which seems like a step in the right direction. (I'm not fond of the all-caps stuff, though. I mean, why? Caps aren't words.) Now if any of those core functions don't work or if I suddenly have to be _aware_ of the experience of using a tool rather than the experience of development, just watch me howl! So far, the jury's still out on that score. I'm not deep enough into it to tell yet, but those are the sorts of problems I'm likely to report. VS2010 was fine for C# development but I found it sluggish and awkward for C++. For instance, IntelliSense often couldn't keep up and went away completely with /CLI in place. That's one place I'm hoping for improvement in VS11. We'll see.

As I recall - ground up fiberglass would be really _bad_ for a person, right? Maybe the poacher or his customer won't be so hard to find...

Don't think of it as A supplants B supplants C. As our industry grows from its infancy through childhood perhaps into adolescence - remember, it didn't really exist before the '50s - we learn ways of thinking that work. New ways of thinking don't supplant what we've learned before. We still use structured programming in writing functions. We use functions in writing objects. We use objects in design patterns. We use design patterns in Test-Driven Development. Cohesion and coupling are still primary considerations in design. This growth happens when what we're programming on changes. Today this would definitely include cloud computing - using computes as needed on pooled computation resources - and massively parallel programming - 8, 16, 64, 128, more processors. Both of these affect how you think about and manage objects. Both of them affect the algorithms you use. Most importantly, they both force you to think of computation cycles as a pooled resource, like memory or disk space, that your program explicitly asks for as needed, rather than something implicitly woven into the design and taken for granted. So if you want something to sink your teeth into, start there. There are a lot of good ideas out there and some of them will coalesce into the generally accepted approach to computing in the next decade - and yes, the work will continue to involve structured algorithms and functions and objects and patterns and unit tests.