Exceptions in sepple

How do you manage exceptions in sepple? I experimented this some time ago. I thought it was a good pattern, but it led me to death:


#include <exception>
#include <string>
using namespace std;

/* This one is used for exceptions in memory management */
class MemoryException : public exception {
   private:
     string error;
   public:
     const char *what() {
       return error.c_str()
     }
     virtual ~MemoryException() throw() {};
     MemoryException &setError(string e) {
       error = e;
       return *this;
     }
};

Used as follows:

class HowAreYou {
  private:
    MemoryException error;
  public:
    void some_failing_method() throw (MemoryException) {
      throw error.setError("Oh, crap, I failed!");
    }
}

What do you think about it?

sepples
I manage to avoid them by not using sepples.

>>1
good pattern
Does. Not. Compute.

>>3
Exactly, a design pattern is a fundamental weakness in a language. Real languages would allow you to abstract that pattern away nicely.

>>4
Yes, but you know that sepples is not a good language, nevertheless is used in a lot of situations, and I think that collecting good patterns is a good way to face the needing of modifying existent sepples programs.

>>5
Just like ``web developers'' collect bits of Javascript and PHP to use?
Design patterns are symptomatic of a poor language, but also of a poor programmer.

>>6
Oh, come on Anonymous... Are you telling me that when you was younger and noticed that your code was sucky you kept writing code in the same way? Are you telling me that when you discovered a new way of programming (e.g. callbacks) you didn't say "well, this may be useful"?

I agree on your point if we talk about languages: a poor language requires more design patterns in order to a void language suckyness (and this is expecially true for C++, where IMHO you should avoid references if you can).

>>7
when you was

>>6
Design patterns are symptomatic of a poor language, but also of a poor programmer.
With the first point I can agree, the second is sort-of-right but up to a point. Average programmers don't see the real reason for which design patterns exist. They see it as a good tool and that's ok. If they use the the pattern correctly, there's no harm done. It's actually beneficial to the whole team because it's a standard everyone can understand (sort of a common denominator). The thing that differentiates a good and average programmer is the deeper meaning behind the pattern: the pattern is a symptom of a language deficiency. There's nothing inherently wrong in using design patterns but there are some people that just couldn't help but take it too far. Those people have created Java and lo and behold it became the most popular enterprise language to date.

You should use design patterns because thats the right way and not because they was written down in some book...

>>7
when you was younger
>>10
they was written down

Hmm...

>>1
What the fuck is you trying to imply?

>>11
I'm going to guess that >>10 was making fun of ignorant people.

>>12
That you are a n Irish

>>14
This thread needs some CROMA

>>15
GIVE US THE SOURCE CODE ALREADY YOU GINGER CUNT

>>16
After I'm done banging the Culver, bitch.

>>17
You've been pounding away at that labia for over a year, it must smell like fish by now

/prog/, srsly, how do you suggest to write exceptions in sepples?

http://www.google.com/search?q=exceptions+c%2B%2B&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a