Code review - hilarious code snippets

[NickFitz]

The BBC Micro was not multithreaded, Shirley?

Correct (although I did once implement a pre-emptive task switcher on it, just for fun). The crash disappeared purely because the addition of the logging code moved stuff up in memory to where it was no longer on a page boundary.

[suityou01]

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?

Totally and has been for a while, I was just having too much fun trolling.

One has to dish it back out once in a while.

[Sysman]

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.

Yep. BTDT, though not on a BBC micro.

That optimising FORTRAN compiler was fun in its .0 version too. Its saving grace was its ability to generate assembly listings of the code it was churning out so you could see where it was barfing.

[TheFaQQer]

Totally and has been for a while, I was desperately hoping that my incompetence would go ignored if I kept banging on about it enough - hey, I've turned it into a career, so why shouldn't it work here!!

FTFY

[TheFaQQer]

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?

If you're using Oracle, you can still get an exception thrown even when nothing has gone wrong. Maybe that's the point SY was trying to make?

[eek]

Odious hypocritical little turd.


HTH

Totally and has been for a while, I was just having too much fun trolling.

One has to dish it back out once in a while.

As I said above I see you know what you are. And you wonder why we take the mickey out of your problems!!!!

[eek]

If you're using Oracle, you can still get an exception thrown even when nothing has gone wrong. Maybe that's the point SY was trying to make?

oracle doesn't throw errors for the sake of it. If its throwing an error something will have gone wrong (although it probably has sod all to do with what you are trying to get it to do).

[doodab]

If you're using Oracle, you can still get an exception thrown even when nothing has gone wrong. Maybe that's the point SY was trying to make?

Yes but i'm talking java.

As you say, Oracle makes the whole debate moot with it's no_data_found exception anyways...

[darmstadt]

Signal On Syntax
Signal On Novalue
Signal On Halt
Signal On Error
Signal On Failure

Works for me...

[d000hg]

Not so sure about that. In an early attempt to do something with Objective-C strings I created a memory leak in a tight processig loop. That brought the machine to its knees - the swapfile hit 3GB on a 640 MB system, and was growing

A reboot was the only way out.

Interesting. However couldn't you get the same problem running Java if you set the memory limit much higher than the physical RAM on the system?