Are you kidding me?

[TheBuzzSaw]

Just found this today in our C# code base.

Code: Select all

try
{
    DoLotsOfImportantStuff();
    DoMoreImportantStuff();
    Etc();
}
catch (OutOfMemoryException ex)
{
    // EMPTY
}

"Hey! You're out of memory!"
"Meh. Don't worry about."

[Falco Girgis]

[k1net1k]

lol

[dandymcgee]

Rofl.

[Falco Girgis]

If I had exceptions enabled, that would be how I'd handle running out of RAM on the Dreamcast in ES...

[Nokurn]

This sounds like something you'd see on thedailywtf.com.

If I had exceptions enabled, that would be how I'd handle running out of RAM on the Dreamcast in ES...

I've been wanting to move away from exceptions, and I should probably make a new topic to ask about this, but what strategy do you use for signaling errors in your classes? Do you only use the constructor for POD initialization and use a separate method for doing the heavy lifting?

[Falco Girgis]

This sounds like something you'd see on thedailywtf.com.

If I had exceptions enabled, that would be how I'd handle running out of RAM on the Dreamcast in ES...

I've been wanting to move away from exceptions, and I should probably make a new topic to ask about this, but what strategy do you use for signaling errors in your classes? Do you only use the constructor for POD initialization and use a separate method for doing the heavy lifting?

Yeah, that's essentially it. Load() anything, or anything that can epic fail returns a bool. It's as simple as

Code: Select all

if(!level.Load("directory")) _dbgLog("Something is boned");

[TheBuzzSaw]

What kills me is that this particular application has been crashing left and right, and I found SEVERAL of this kind of try-catch block in the code. You think that if we were out of memory, we should report it, stop what we're doing, and exit. No, it just tries to keep running. It doesn't even ANNOUNCE that it's out of memory! It just goes until it implodes. Brilliant.

[mattheweston]

Pardon my ignorance, but how would you gracefully handle an exception error with a simple if...else ? Wouldn't the exception cause the app to crash? The only alternative would be to identifiy every possible scenario for bad parameters and elimitate them.

I'm sure I'm missing something. Maybe Falco can give us some edjumacation.

[TheBuzzSaw]

Pardon my ignorance, but how would you gracefully handle an exception error with a simple if...else ? Wouldn't the exception cause the app to crash? The only alternative would be to identifiy every possible scenario for bad parameters and elimitate them.

In exception-driven languages, you cannot stop every possible exception from occurring. Eventually, you have to make a decision on how to handle one when it is thrown. (In particular, it seems many database drivers insist on using exceptions as the only way of communicating.) However, you should always avoid making a try-catch part of the normal control flow. Exceptions are just that: exceptions. They should rarely happen. Check to see if your variable == null. Do not simply catch a NullPointerException to make your code clean looking. Log your exceptions as best you can. Try to kill off the situations that throw them.

Ultimately, you should do some exception-catching. Just don't maim your code with it.

[mattheweston]

I think I get what you are saying but, it would be nice to see a snippet of code as an example.

[Ginto8]

I think I get what you are saying but, it would be nice to see a snippet of code as an example.

Take, for example, the OutOfMemoryException of the original post. If you program runs out of memory, you probably want do one of two things: a) make a mad dash to free up some unnecessary memory or b) die noisily, providing as much information about the crash as possible so it can be debugged. For the second, you probably don't need try-catch at all really, since exception reports tend to be pretty verbose anyway.

However, what if you're using that original program as simply one section of a larger program? That larger program might not want to crash when a module runs out of memory; perhaps it just wants to kill the module. Then you'd add a try-catch somewhat like this:

Code: Select all

try {
    Module.doStuff();
} catch(OutOfMemoryException ex) {
    Module.dieInAFire();
}

But I think you were originally asking about Falco's code, not Buzz's.

Code: Select all

if(!level.Load("directory")) _dbgLog("Something is boned");

In this case, nothing is throwing an exception. Allowing exceptions is a rather complicated and costly process, requiring a step-by-step stack unwinding and a runtime check for catch blocks, so Falco decided to disable exceptions. To allow error checking for vital initialization steps that can fail (eg. loading the level), he separated initialization into two parts: the constructor, which would do POD (plain-old-data) initialization, consisting of things that cannot fail, and the secondary initialization(s) such as loading the level. These secondary initializations handle failure-prone processes and return a value indicating success or failure (in this case it returns a true value on success). Since the error is indicated by return, there's no need for an exception, and no need for exception handling. Hence, a conditional is used for error checking.

[mattheweston]

But let's say you have a method to do something

Code: Select all

bool erroredMethod()
{
  bool isSuccessful = false;
  do something;
  do something;  //if this causes an out of memory error(read exception) then the rest of the code doesn't execute
  do something;
  isSuccessful = true;  // how can this be set then ?

}

[short]

But let's say you have a method to do something

Code: Select all

bool erroredMethod()
{
  bool isSuccessful = false;
  do something;
  do something;  //if this causes an out of memory error(read exception) then the rest of the code doesn't execute
  do something;
  isSuccessful = true;  // how can this be set then ?

}

malloc returns NULL when it can't allocate any more memory in C. Higher level languages also provide constructs for informing the programmer that dynamic memory was unable to be allocated (default new in c++ returns NULL as well in every implementation I have seen). If your getting a memory error, check the return of malloc / new for null. if you fail to allocate dynamic memory (new() / malloc()) then set isSuccessful to false and return.

[Van-B]

Hehe, love it :D

Kinda like that VB full-retard-mode command...

On Error Resume Next

In other words, if you crash, just go onto the next command and pretend it never happened.