Code review - hilarious code snippets

[doodab]

I agree returning null from a method where you are querying for a specific object , if its not found then it should return null, not throw an exception as they are expensive, this though leads to lots of if (obj == null) all over the shop.

This is debateable. Testing for a null result is more expensive than a try block if no exception is raised, so if the null result is fairly uncommon (less than 1 in 10 or 20 say) then the overhead of raising the exception occasionally is less than the overhead of checking the result every time.

Personally i go with semantics first approach. If null is a valid result then return it. If it's indicative of a problem throw an exception.

[eek]

Was reviewing some code the other day with the main developer for the site in question. In a comment written a couple of years ago:

/* Here be dragons, proceed with caution */

No clue as to exactly why the dragons existed there or what we should be cautious about

I've written that in the past. Its clue for this code is written by the numpty in the other office but I don't want to insult him by name as with any luck this tulip will end up back in his hands to screw up again.

[russell]

This is debateable. Testing for a null result is more expensive than a try block if no exception is raised, so if the null result is fairly uncommon (less than 1 in 10 or 20 say) then the overhead of raising the exception occasionally is less than the overhead of checking the result every time.

But have you factored in the cost of your crystal ball, that can predict user input. You should never make assumptions about user input.

[doodab]

Java and C# don't run directly on the metal, they are managed by a runtime. Granted you don't see Linux kernel crashing much, but you must remember BSOD, no doubt caused by unmanaged code.

BSOD are usually due to drivers doing something they shouldn't. You can't write kernel mode drivers in .Net AFAIK so it's rather a moot point.

[suityou01]

This is debateable. Testing for a null result is more expensive than a try block if no exception is raised, so if the null result is fairly uncommon (less than 1 in 10 or 20 say) then the overhead of raising the exception occasionally is less than the overhead of checking the result every time.

Personally i go with semantics first approach. If null is a valid result then return it. If it's indicative of a problem throw an exception.

What about encapsulation? You would want to take into your thoughts what happens to the caller if this goes bang? Using a try block with no exception being raised sounds dodgy IMVHO, and runs the risk of creating time bombs.

Just sayin like

[suityou01]

BSOD are usually due to drivers doing something they shouldn't. You can't write kernel mode drivers in .Net AFAIK so it's rather a moot point.

You're quite right. Kernel mode does run "on the metal" and you can only do this in C. The BSOD is known as a bug check and is raised from the Kernel, typically a driver going pop. But then there are other sorts of drivers than device drivers so the term "driver" is a bit nebulous nowadays.

[eek]

What about encapsulation? You would want to take into your thoughts what happens to the caller if this goes bang? Using a try block with no exception being raised sounds dodgy IMVHO, and runs the risk of creating time bombs.

Just sayin like

That wasn't what he was saying. Its the cost of testing for null all the time compared to using a try block with an exception. I don't think anyone has suggested using a try block with no exception (until you arrived).

[suityou01]

That wasn't what he was saying. Its the cost of testing for null all the time compared to using a try block with an exception. I don't think anyone has suggested using a try block with no exception (until you arrived).

Post 44, paragraph 1, sentence 2, clause 1.

HTH BIDI

[russell]

BSOD are usually due to drivers doing something they shouldn't. You can't write kernel mode drivers in .Net AFAIK so it's rather a moot point.

Exactly my point, the .NET runtime protects you from all if the low level details where a badly written program could BSOD.

[russell]

That wasn't what he was saying. Its the cost of testing for null all the time compared to using a try block with an exception. I don't think anyone has suggested using a try block with no exception (until you arrived).

I doubt testing for null is an expensive operation and can probably be optimized by the compiler.