Why yes, yes I am.

Weng

//Snip a try block and a bunch of catches for specific exceptions. All generally wellformed and useful - either handling the exception, or wrapping it as an innerexception with more info and rethrowing it.

                catch (OutOfMemoryException x)
                {
                    //Well you're just fucked now, aren't you?
                    throw x;
                }

The original developer is my new favorite.

ltouroumov

@Weng said:

catch (OutOfMemoryException x)

{

//Well you're just fucked now, aren't you?

throw x;

}

Is the comment original ?

Can't you free some resources (like useless objects etc...) in that call ? (I don't know I havent done Java since school)

AngelSL

That is C#, not Java. Java has OutOfMemoryError, not OutOfMemoryException.

Rene

@ltouroumov said:

@Weng said:
catch (OutOfMemoryException x)
{
	//Well you're just fucked now, aren't you?
	throw x;
}
Is the comment original ?

Can't you free some resources (like useless objects etc...) in that call ? (I don't know I havent done Java since school)

So it's out of memory now?

ltouroumov

@AngelSL said:

That is C#, not Java. Java has OutOfMemoryError, not OutOfMemoryException.

Really long time ! (I really looks like Java when you don't look too close)

@ltouroumov said:

@Weng said:
catch (OutOfMemoryException x)

{

//Well you're just fucked now, aren't you?

throw x;

}
Is the comment original ?

Can't you free some resources (like useless objects etc...) in that call ? (I don't know I havent done Java since school)

I was asking if the comment was in the original code

English is not my primary language, so stupid expressions like this pop up when Im not focused

funluvncriminal

@AngelSL said:

That is C#, not Java. Java has OutOfMemoryError, not OutOfMemoryException.

Plus, the java syntax for rethrow is simply throw; rather than throw x;

Normally I hate people who are this pedantic, and i'm sure i've made a spelling mistake for someone to pick up on, but, i'm bored tonight.
Oh, and speaking of pedantic, did i mention that the compiler will probably optimize this out anyway.

@funluvncriminal said:

Plus, the java syntax for rethrow is simply throw; rather than throw x;

No. It's vice versa.

serguey123

@funluvncriminal said:

Plus, the java syntax for rethrow is simply throw; rather than throw x;

Normally I hate people who are this pedantic, and i'm sure i've made a spelling mistake for someone to pick up on, but, i'm bored tonight.
Oh, and speaking of pedantic, did i mention that the compiler will probably optimize this out anyway.

Hmmm the irony is there somewhere.

From the specification http://msdn.microsoft.com/en-us/library/ms182363(VS.80).aspx

Read it please, both throw x and throw are valid, only the latter preserves the stacktrace, there is a difference between explicit and implicit

Deprecated

@Spectre said:@funluvncriminal said:Plus, the java syntax for rethrow is simply throw; rather than throw x; 

No. It's vice versa.catch (OutOfMemoryException x)
{
    //Well you're just fucked now, aren't you?
    vice versa;
}

Help, it's not working!!!

dogbrags

@Weng said:

//Snip a try block and a bunch of catches for specific exceptions. All generally wellformed and useful - either handling the exception, or wrapping it as an innerexception with more info and rethrowing it.
                catch (OutOfMemoryException x)
                {
                    //Well you're just fucked now, aren't you?
                    throw x;
                }
The original developer is my new favorite.

Normally, you catch exceptions for one of two reasons;

1) logging the exception at the point of occurrance; and then you propigate it (rethrow it) so that the correct handler further up the chain can handle it

2) if you can handle the exception at that point and recover from the error

If you can't do either one, then there is no point in catching it. So don't bother; assume that somewhere up the chain is a handler for it. For out of memory exception, it's likely that the program can't continue anyway.

HighlyPaidContractor

@dogbrags said:

Normally, you catch exceptions for one of two reasons;

1) logging the exception at the point of occurrance; and then you propigate it (rethrow it) so that the correct handler further up the chain can handle it

2) if you can handle the exception at that point and recover from the error

If you can't do either one, then there is no point in catching it. So don't bother; assume that somewhere up the chain is a handler for it. For out of memory exception, it's likely that the program can't continue anyway.

There's also the possibility that there's a catch(Exception x){ } block somewhere below this particular example that logs all remaining exception types, but the developer didn't want to log OutOfMemory. Not the best way to go about it, but still valid.

There's also the chance that he caught it for the sole purpose of making a joke.

Or that the block originally did some additional processing that was later removed and we're looking at a vestigial handler.

eBusiness

@dogbrags said:

Normally, you catch exceptions for one of two reasons;
1) logging the exception at the point of occurrance; and then you propigate it (rethrow it) so that the correct handler further up the chain can handle it
2) if you can handle the exception at that point and recover from the error
If you can't do either one, then there is no point in catching it. So don't bother; assume that somewhere up the chain is a handler for it. For out of memory exception, it's likely that the program can't continue anyway.

3) Someone who don't know a lot about programming, yet make decisions about programming, decided that all exceptions must be caught.

BPFH

@eBusiness said:

3) Someone who don't know a lot about programming, yet make decisions about programming, decided that all exceptions must be caught.

...which would explain this, seen repeatedly in our in-house web development framework:

catch (Exception e)
{
    throw new Exception(e.Message);
}

Talk about losing the stacktrace...

smxlong

@dogbrags said:

Normally, you catch exceptions for one of two reasons;
1) logging the exception at the point of occurrance; and then you propigate it (rethrow it) so that the correct handler further up the chain can handle it
2) if you can handle the exception at that point and recover from the error
If you can't do either one, then there is no point in catching it. So don't bother; assume that somewhere up the chain is a handler for it. For out of memory exception, it's likely that the program can't continue anyway.

You want to stick a breakpoint there sometimes.

nonpartisan

@smxlong said:

@dogbrags said:
Normally, you catch exceptions for one of two reasons;
1) logging the exception at the point of occurrance; and then you propigate it (rethrow it) so that the correct handler further up the chain can handle it
2) if you can handle the exception at that point and recover from the error
If you can't do either one, then there is no point in catching it. So don't bother; assume that somewhere up the chain is a handler for it. For out of memory exception, it's likely that the program can't continue anyway.

You want to stick a breakpoint there sometimes.

4) You expect to eventually do something else with the exception so you wanted to have stub code available.

5) You wanted to put in a very pointed comment to emphasize the situation or so that someone else would have material to post on TDWTF.

Weng

@HighlyPaidContractor said:

There's also the chance that he caught it for the sole purpose of making a joke.

This.

Yes, the comment is original. Nowhere else in the program is an OOME handled (and rightfully so - if you can make this thing run out of memory, it's because you're trying to do it) and this comes at the end of a long group of catch blocks that cover, individually, every single possible exception that can be thrown there.

Aren't you a little young to be catching OutOfMemoryExceptions?

Weng

@Anonymouse said:

Aren't you a little young to be catching OutOfMemoryExceptions?

You're never too young to play around with 4 gig datasets and 32bit executables.

eBusiness

Catch and release is common among sport fishers, why shouldn't it be among coders?

@eBusiness said:

Catch and release is common among sport fishers, why shouldn't it be among coders?

Try is common. Catch, not so much.

dhromed

Try? There is no try. There is only catch, or crash.

fatbull

@El_Heffe said:

@eBusiness said:
Catch and release is common among sport fishers, why shouldn't it be among coders?
Try is common. Catch, not so much.

That's why it's called Exception Angling.