Code review - hilarious code snippets

[eek]

Absolutely. The original statement was about having a try block without raising an exception.

How on earth is suityou01 worth their rate?

unless it is as cheap scapegoat for obvious disaster.

[suityou01]

How on earth is suityou01 worth their rate?

unless it is as cheap scapegoat for obvious disaster.

Odious hypocritical little turd.

Current project is turning around. See sig.

HTH

[d000hg]

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

No. A regular C++ app can't do all the stuff a low-level driver can. A regular Windows C++ app would have to do something pretty special to cause a BSOD, since every app has its own memory space, etc.

[doodab]

Absolutely. The original statement was about having a try block without raising an exception.

No, it was about what happened in the case the code in the try block didn't raise an exception. There was no implication that it would *never* raise an exception, if that was the case there would be no need for the try-catch anyway, nor any suggestion that an exception would go unhandled.

[NickFitz]

Every time I try and remove this line it all stops working.

I remember writing a sprite rendering routine in 6502 assembler on the BBC Micro. It crashed for no apparent reason, so I added a few bits of code to log values at important junctures. Lo! it worked

So I removed the logging code and it crashed again

As I sat there baffled, I idly ran the assembler over it again and, as the listing scrolled up the screen, I suddenly realised what it was - I'd fallen victim to the 6502's JMP indirect bug:

JMP (<address>), is partially broken. If <address> is hex xxFF (i.e., any word ending in FF), the processor will not jump to the address stored in xxFF and xxFF+1 as expected, but rather the one defined by xxFF and xx00.

Hours of fun...

[eek]

Odious hypocritical little turd.

I see you are talking about yourself again.

[doodab]

I remember writing a sprite rendering routine in 6502 assembler on the BBC Micro. It crashed for no apparent reason, so I added a few bits of code to log values at important junctures. Lo! it worked

So I removed the logging code and it crashed again

As I sat there baffled, I idly ran the assembler over it again and, as the listing scrolled up the screen, I suddenly realised what it was - I'd fallen victim to the 6502's JMP indirect bug:

JMP (<address>), is partially broken. If <address> is hex xxFF (i.e., any word ending in FF), the processor will not jump to the address stored in xxFF and xxFF+1 as expected, but rather the one defined by xxFF and xx00.

Hours of fun...

Another common cause of such wibbliness is race conditions in multithreaded code. The overhead of logging, or synchronisation in the logging code, often makes the race condition disappear.

[suityou01]

Another common cause of such wibbliness is race conditions in multithreaded code. The overhead of logging, or synchronisation in the logging code, often makes the race condition disappear.

The BBC Micro was not multithreaded, Shirley?

[suityou01]

No, it was about what happened in the case the code in the try block didn't raise an exception. There was no implication that it would *never* raise an exception, if that was the case there would be no need for the try-catch anyway, nor any suggestion that an exception would go unhandled.

This is debateable. Testing for a null result is more expensive than a try block if no exception is raised

Only sayin like

[doodab]

Only sayin like

Right. Try reading the whole thread. I started by complaining about people who return null instead of throwing exceptions.

So, i'm comparing two methods of notifying a caller that a problem was encountered.

A) returning null from a method to indicate an error and requiring the caller to check the result of every invocation

B) throwing an exception when the method cannot complete normally, and having caller use a try catch block

And i'm saying that try catch is more efficient in the situation that the code completes normally and no exception is raised.

There is only no exception in the case that nothing goes wrong when the method is called. Is that clear?