The Daily WTF: Curious Perversions in Information Technology

chrismcb · 2006-02-06 Reply Admin

FunnyMan:
chrismcb:
Actually it is called an exception handler and it is how professionals handle exceptions in their code. This allows you to have a generic exception handler to handle the exceptions.
IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.

I guess I don't understand how you plan on handling your errors WITHOUT using on error goto?

The better solution is to have the error handling alongside the code that triggers that error (with, say, a try-catch block). It makes it easier to figure out which error is being handled by what code, and if you happen to have a bunch that all need the same fix, you dump it in a function and call the function. I'm thankfully not up to date on VB, so I can't tell you if such a construction even exists, but it's definitely the Right Way to handle errors (unless used as above).

-FM

I'm not saying that "On error goto" is good, or great. But giving older versions of VB, you had three choices:

Do nothing (let the program crash)

On error resume next

on error goto.

Thats it. The try catch IS "one error goto".

Instead of:

try { do something} catch {fixit}

do:

on error goto ErrorHandler

do something

exit function //whatever, finish processing, etc

ErrorHandler:

fix it

Yeah the "on error goto" isn't quite as clean, because it is essentialy just a goto. But it is WAY better than on error resume next. And it is the only way to handle exceptions in previous versions of VB.

2006-02-06 Reply Admin

Anonymous:
Whie the Java version is nice, there is still to much code hardcoded in the, uh, code. What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.

Why don't you at least read through your posts and correct your fucking typos, you motherfucking moron? It's not that hard, and we will likely even think that you are more that a pile of shit kept together by a filthy greasy sack of white skin flaps.

2006-02-06 Reply Admin

chrismcb:
IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.

No, it isn't. In the face of many errors (and quite potentially the majority) it's the only sane behavior to take, because the error that occurs is inherently unrecoverable.

And if you cannot recover and resume normal operation, then the only correct beavhior is to crash imediately, gracefully (meaning attempt to save work or whatever where possible), and with as much useful information as possible.

2006-02-06 Reply Admin

Anonymous:
Anonymous:
Whie the Java version is nice, there is still to much code hardcoded in the, uh, code. What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.

Why don't you at least read through your posts and correct your fucking typos, you motherfucking moron? It's not that hard, and we will likely even think that you are more that a pile of shit kept together by a filthy greasy sack of white skin flaps.

Not nice, like that talking. Maybe someone types in Foreign Language? How good you in non-english?

chrismcb · 2006-02-06 Reply Admin

Anonymous:
chrismcb:
IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.
No, it isn't. In the face of many errors (and quite potentially the majority) it's the only sane behavior to take, because the error that occurs is inherently unrecoverable.

And if you cannot recover and resume normal operation, then the only correct beavhior is to crash imediately, gracefully (meaning attempt to save work or whatever where possible), and with as much useful information as possible.

Crashing is the only SANE behavior to take? Were you one of the designers of the Titanic? Yeah there are times when it is hopeless and it is impossible to recover from the errors. BUT that should be a last resort. You should do EVERYTHING in your power as a programmer to prevent the program from crashing and losing the users data.

Ohhh the user wanted to divide by zero, lets crash. I wasn't able to access the data base, hell must be freezing over, lets crash. Ohhh found a null pointer, which way did he go George, lets crash.

But lets also look at what you said.. ".. gracefully (meaning attempt to save..." Well how are you going to be graceful, and attempt to save work if you don't have an exception handler? If you want to do ANYTHING other than crash, you have to use "on error goto." (err you could also implement on error resume next, but, well...

Maurits · 2006-02-06 Reply Admin

chrismcb:
Crashing is the only SANE behavior to take? Were you one of the designers of the Titanic?

Had the Titanic resigned itself to the crash and hit the iceberg head-on, it would not have sunk.

It got in trouble because it tried to be clever and avoid the inevitable.

robbak · 2006-02-06 Reply Admin

Here's something to make it simpler:

define KQ(code) try{ code }catch{}

KQ( cout << "hello world";)

(Yes, of course it will crash. The sight of someone trying to debug something like that may be painfull. Fun, but painfull.

mcrbids · 2006-02-06 Reply Admin

Manni:
One alternative is "On Error Goto", which is just frickin scary and amateurish to use. I want to handle my errors, not jump to a certain line in my code whenever something goes wrong. I suppose you could just omit error-handling completely and let the program crash when you encounter such a problem. I wouldn't recommend it.

I've seen an equivalent type of function in PHP,

Set_Error_Handler('functionName');

Since I discovered this little gem, it's made my life SOOOO much easier... It allows me to catch any/all minor errors and the like in a log file, out of sight, but available for my preview. By having a function used to catch both language errors and application errors, I can have a single log file that, when viewed, gives a sequential history of errors, and by burying it into a log file, I can watch what happens for a specific user, even though the system may be processing hundreds of sessions simultaneously!

I guess this is sorta like your "goto", but PHP's take is to combine this with "On Error Next" so that not only can I properly trap errors within the program, but I can also identify them after the fact with a grep of the log file.

Very, very, VERY cool, says I!

BTW: The following looks to be a PHP equivalent of what this guy did:

Function CatchError($errno, $errstr)
{
return false;
}
Set_Error_Handler('CatchError');

2006-02-06 Reply Admin

chrismcb:
Crashing is the only SANE behavior to take?

Yes. For example, if you trigger an exception that really indicates a logic-error (i.e., something that should never happened unless the programmer fucked up), then the only sane recourse ever is crashing.

Also, there's a whole class of runtime errors where the only recourse is to crash, or where the only sane recourse is to crash unless you know it's a retriable condition (e.g., OOM, can't spawn a thread, can't open an FD). Even if it's not retriable, it very well may not matter anyway as such errors are frequently the harbingers of impending doom and it may be impossible for you to continue.

You should do EVERYTHING in your power as a programmer to prevent the program from crashing and losing the users data.

The latter, not the former. The two aren't exclusive, you know.

If you want to do ANYTHING other than crash, you have to use "on error goto." (err you could also implement on error resume next, but, well...

I wasnt' talking about VB, I was talking generally. This entire notion that 'programs should never crash' is silly, unless the program is bug-free and the system can never enter a failure state.

I'd infinitely perfer programs that crashed in the face of an error that was unrecoverable (or they didn't think they'd recover from) whilst automatically saving my work, and giving me a real message. The typical consequence otherwise is much far worse, especially if it failed due to something like 'Couldn't fork', which means there's something else I need to be looking at.

chrismcb · 2006-02-06 Reply Admin

Anonymous:
I'd infinitely perfer programs that crashed in the face of an error that was unrecoverable (or they didn't think they'd recover from) whilst automatically saving my work, and giving me a real message. The typical consequence otherwise is much far worse, especially if it failed due to something like 'Couldn't fork', which means there's something else I need to be looking at.

Once an exception occurs, one of two things will happen. Either the program will handle the exception, or the mechanism running the program will handle the exception. Generally if the mechanism running the program handles the exception, it will display a useless error message, and stop the program from running. The program won't have any chance to do anything, it gave up that chance by not handling the exception.

Whether or not the program should be allowed to crash is still up for debate, but everyone seems to agree that the program should at least step in and save user data, and "crash gracefully."

This means the program has to have an exception handler. So we all seem to be in agreement that you need an exception handler. In VB (prior to VB.Net) you implemented exception handlers by using "on error goto." Which the person who I initialy responed too said was amateurish and shouldn't be used.

2006-02-06 Reply Admin

chrismcb:
Once an exception occurs, one of two things will happen. Either the program will handle the exception, or the mechanism running the program will handle the exception.

Correct, and in handling the exception one can terminate the program manually (performing the same task as the language-installed handler and "crashing" after performing some desired operation) or by rethrowing the exception and letting the language-installed handler take care of that.

The program won't have any chance to do anything, it gave up that chance by not handling the exception.

You can still let both do the work. Error propogation is possible in every language, including VB6, though in VB6 it would probably be eaiser to just abort the program on conclusion of the error handler.

But in C++, Java, C#, and most other languages with exception handling you'd just rethrow.

This means the program has to have an exception handler.

Which doesn't preclude the exception handler from terminiating the program, which is a crash.

2006-02-06 Reply Admin

Anonymous:

That is just fscking ridiculous. I can't believe someone would go to those lengths to avoid ever getting an error... ever (much less never know if their code is ever working or not).

Oh no, this is an anti-pattern that comes up repeatedly in WTF: the coder who is so terrified of seeking out help with the language or platform that he will deliberately inflict pain on himself and others to avoid it.

Jeff S · 2006-02-06 Reply Admin

chrismcb:
FunnyMan:
chrismcb:
Actually it is called an exception handler and it is how professionals handle exceptions in their code. This allows you to have a generic exception handler to handle the exceptions.
IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.

I guess I don't understand how you plan on handling your errors WITHOUT using on error goto?

The better solution is to have the error handling alongside the code that triggers that error (with, say, a try-catch block). It makes it easier to figure out which error is being handled by what code, and if you happen to have a bunch that all need the same fix, you dump it in a function and call the function. I'm thankfully not up to date on VB, so I can't tell you if such a construction even exists, but it's definitely the Right Way to handle errors (unless used as above).

-FM

I'm not saying that "On error goto" is good, or great. But giving older versions of VB, you had three choices:

Do nothing (let the program crash)

On error resume next

on error goto.

Thats it. The try catch IS "one error goto".

Instead of:

try { do something} catch {fixit}

do:

on error goto ErrorHandler

do something

exit function //whatever, finish processing, etc

ErrorHandler:

fix it

Yeah the "on error goto" isn't quite as clean, because it is essentialy just a goto. But it is WAY better than on error resume next. And it is the only way to handle exceptions in previous versions of VB.

good post. However, you can use still "on error resume next" safely and intelligently in good old VB (I used it all the time), as long as you know to use "on error resume 0" immediately after the statement you are trying. This "disables" the "resume next" error handling, and allows you to avoid the goto/resume error handling if you prefer to keep it somewhat sequential in your code. (I actually feel doing it that way is closer to try/catch than the goto/resume method).

Very few people seem to know about "on error resume 0" -- probably because the syntax is so weird and it isn't obvious what the heck it means!

2006-02-06 Reply Admin

EVIL! You are Eeeeeee-vil !!!

But your proposed method of programming does remove those pesky compiles from the um, development process...

Just promise you'll never say anything like that with a manager in the room. Ever. Please. He's not in on the joke, and we'd have to kill you.

2006-02-06 Reply Admin

FrostCat:
Anonymous:

Anonymous:
Okay, I'm going to poke a few here, but the first sentence got me.

"On Error Resume Next"

As a (typically) non-VB programmer, this strikes me as:

"I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

Thanx
Diablo.

It depends on what the "next" is in resume next. This should be some sort of error handler, if coded correctly.

And this case, "correctly" probably means using "on error goto", not "on error resume next".

This post not [pi]-approved.

Touche. Of course, to be REALLY correct, don't use VB in the first place! (At least pre-.NEt VB)

2006-02-06 Reply Admin

Anonymous:
Whie the Java version is nice, there is still to much code hardcoded in the, uh, code. What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.

EVIL! You are Eeeeeee-vil !!!

But your proposed method of programming does remove those pesky compiles from the um, development process...

Just promise you'll never say anything like that with a manager in the room. Ever. Please. He's not in on the joke, and we'd have to kill you.

gggrrr. the WTF that is this forum software strikes again. Really, it's god-awful. Can I just get a freakin' preview function, please? gah.

chrismcb · 2006-02-06 Reply Admin

Jeff S:

good post. However, you can use still "on error resume next" safely and intelligently in good old VB (I used it all the time), as long as you know to use "on error resume 0" immediately after the statement you are trying. This "disables" the "resume next" error handling, and allows you to avoid the goto/resume error handling if you prefer to keep it somewhat sequential in your code. (I actually feel doing it that way is closer to try/catch than the goto/resume method).

Very few people seem to know about "on error resume 0" -- probably because the syntax is so weird and it isn't obvious what the heck it means!

Sure, just like you can use on error goto 0 to remove your exception handler. Except that "on error resume next/statement/on error resume 0" still gobbles the exception. You are disabling the exception handling for that one statement.

It is the equivalent to try { something } catch {}

foxyshadis · 2006-02-06 Reply Admin

Anonymous:
gggrrr. the WTF that is this forum software strikes again. Really, it's god-awful. Can I just get a freakin' preview function, please? gah.

You're too new the understand, but the preview was there. It shows what you typed, oh yes, quite nicely. Then you post and it spews garbage anyway. This really is a pathological board, the online edition of Windows 95 with 4 megs of bad memory. Maybe that's what telligent develops on?

2006-02-06 Reply Admin

Manni:

Is there another language that automatically does something (other than crash the program) whenever an error is generated? If so, please tell me so I can begin using it immediately.

That would be TCL, also commonly used for writing GUI apps. It has much better cross-platform support than VB will ever have, too.

Gene Wirchenko · 2006-02-06 Reply Admin

Anonymous:
Manni:

Is there another language that automatically does something (other than crash the program) whenever an error is generated? If so, please tell me so I can begin using it immediately.

That would be TCL, also commonly used for writing GUI apps. It has much better cross-platform support than VB will ever have, too.

Or C. C has a built-in on error resume next. For example, if you overflow an int, the program might not crash. The results are undefined. That makes perfect sense if you want to ignore errors.

VB6 on the other hand will throw an error (unless you turn this setting off).

Sincerely,

Gene Wirchenko

2006-02-06 Reply Admin

Anonymous:
Okay, I'm going to poke a few here, but the first sentence got me.

"On Error Resume Next"

As a (typically) non-VB programmer, this strikes me as:

"I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

In my opinion, there are a couple good places to use 'On Error Resume Next' and there are a couple of times I've wished C# had an equivilent. Remember, On Error Resume Next doesn't create bad code, bad coders create bad code.

The only place I see On Error Resume Next as acceptable is when you're cleaning up. For example, you're destroying an instance of an object or exiting an application. It might be perfectly acceptable to take the approach of 'Well, I'm shutting down so I don't relaly care if an exception occurs'.

The other place I've used it is in the VB world of On Error Goto. It can be useful when in these error handeling routines. You don't really want to specify another On Error Goto so a better way is to specify on On Error Resume Next so that you can attempt to continue cleaning up even if an error occurs partway through that cleanup.

Finally, there are times when you just don't care if a particular statement doesn't execute... it may just not be important. There are occations (not many) where this may be the case. Take the example of a logger that logs to different destinations. You may have the following bit of code:

LogViaEmail()
LogViaFileWriter()
LogViaFooBar()

Who cares if the E-mail logging failed. You still want to attempt to log to a file. Sure, the above may be lazy and may not be the best way of accomplishing it, but it is quick and easy to understand. Resume Next has it's uses, but as with anything, care must be taken not to misuse it.

2006-02-06 Reply Admin

The biggest WTF here is the name "SafeCodeDelegate"

Captcha #1 = tastey

smurf · 2006-02-06 Reply Admin

Should have used a programming language that just doesn't crash and doesn't report any errors, but blindly plods on, by design.

Perl comes to mind.

2006-02-07 Reply Admin

I once had a C++ project which included a Tcl language interpreter. Tcl is written in C, and one of the things you often want to do with Tcl is define a whole lot of callbacks from Tcl code to C or C++ so that Tcl scripts can control your larger application.

Unfortunately, Tcl's interface is C, so C++ exceptions can't be used; however, the rest of the application is C++ which uses exceptions in error cases. What to do?

The answer was something like the last example: a C++ template class with a static function, callable from C, which converted the Tcl environment into C++ objects, called a C++ function to do the work, and converted C++ exceptions to an int return value plus setting the Tcl error state. The C++ function that does the work is an argument to the template class, which makes the compiler autogenerate all the annoying glue code that doesn't change 99% of the time (the remaining 1% can be coded manually).

The difference between something sane and this WTF is that a non-zero int return value from a command function is an exception in Tcl, so the errors are being translated, not ignored. All exceptions have to be caught before returning to Tcl, even the unexpected ones, since the program will generally terminate the instant a C++ exception hits a C stack frame.

2006-02-07 Reply Admin

He could have done it VB style in Java :

public void something() throw Exception {
}

Thank god he found a better solution :S

2006-02-07 Reply Admin

Now THIS one was funny. Thanks Alex!

Favorite quotes.. and thank you for brightening my day:

1.

I am reminded of a quote from Hoare. Paraphrase: There are two ways to program: so that there are obviously no errors and so that there are no obvious errors.

2.

Whie the Java version is nice, there is still to much code hardcoded in the, uh, code. What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.

3.

This one is more nightmarish than funny. Someone like this discovering generics is like a baby finding a loaded handgun.

--

yours sincerely sincerity itself

WWWWolf · 2006-02-07 Reply Admin

Anonymous:
Whie the Java version is nice, there is still to much code hardcoded in the, uh, code. What he needs to do is to move all those function names and arguments to an XML file and write a class to parse that and execute it through reflection, all the while discarding all those pesky exceptions.

Bah. It'd be better to write a compiler that compiles the error-free program to an XML file, and an interpreter that runs the compiled error-free XML file.

Or something along those lines.

2006-02-07 Reply Admin

The worst of it : an exception can still be thrown in the affectation part ! (if he access a property set for example)

Do you imagine ? He feel likes it's an art to have exception-free program, he's seeking a graal of programmation perfection and he have to seek again for some weeks ... This megalomania give all the taste to that error.

2006-02-07 Reply Admin

Sticking up for On Error Resume Next...this is how to use it to avoid swallowing all errors:

On Error Resume Next
'do something that you think might give an error
If err.number = 10 then 'the number of the error you think might happen
'handle it
else
'do whatever you want with an unexpected error - probably raise it to the calling function
end
on error goto 0

If you test for the error number and re raise (throw) if it's not what you expect then it's the same as a try/catch{something} block.

And why would you do it? Well, in Excel VBA (I know, it gets worse) - the simplest way to find if things exist (eg worksheets, ranges etc) is to have a function that does:

On Error Resume Next
set ws = workbook.sheets("someName")
sheetexists = (err.number = 0)

The On error resume next stops when you leave the function anyway. Yes, there are other ways to do it - but I've seen this a lot!

2006-02-07 Reply Admin

Alex Papadimoulis:

  try { title = service.GetTitle(); } catch {}
  ...
  try { appName = query.Item["App_Name"].Trim(); } catch {}
  ...
  try { user = requestContext.Identity.User; } catch {}

<t><t><t>
title = Utility.TryCode<string>(delegate {return service.GetTitle();});
...
appName = Utility.TryCode<string>(delegate {return query.Item["App_Name"].Trim();});
...
user =  Utility.TryCode<string>(delegate {return requestContext.Identity.User;});</t></t></t>

Come on, guys, it got just worse with each 'improvement'. With this delegate stuff you need to type (copy-paste) *much* more than with the simple try{}catch{}. I'd prefer the first one, that's pretty neat.
Readability could be improved though. The best would be having the effect but not having to see trys and catches everywhere. I mean, who wants to see those stupid things, their only purpose is to get rid of exceptions. We need some sort of transparent solution. So... I'd adjust the syntax highlighter so that the try and catch keywords have almost the same color as the background, so they don't bother any more:

try { title = service.GetTitle(); } catch {}
  ...
try { appName = query.Item["App_Name"].Trim(); } catch {}
  ...
try { user = requestContext.Identity.User; } catch {}

Now the exceptions are handled (trashed) 'transparently' :)))

2006-02-07 Reply Admin

Manni:
Devils Advocate:
Okay, I'm going to poke a few here, but the first sentence got me.

"On Error Resume Next"

As a (typically) non-VB programmer, this strikes me as:

"I'm not going to write well written code, if something goes wonky, just ignore it and keep on truckin'!"

Now, this to me, seems like it might work in the non-production scripting world, but is this seriously the "recommended practice" for dealing with realtime errors?

Thanx
Diablo.

"On Error Resume Next" does have its place in the VB world, but just like anything else, in the wrong hands it can wreak havoc.

Your interpretation of the statement is fairly accurate. However you can test at any point in your code to see if an error occurred, and account for it (this is how you tell good programmers from hobbyists). These errors don't necessarily result from poorly written code, there are plenty of valid reasons: database server went down as the program was running, query timeout was exceeded, no read permission on remote files, etc etc. This is stuff you can't always test for or anticipate.

One alternative is "On Error Goto", which is just frickin scary and amateurish to use. I want to handle my errors, not jump to a certain line in my code whenever something goes wrong. I suppose you could just omit error-handling completely and let the program crash when you encounter such a problem. I wouldn't recommend it.

You can anticipate that a db server will not always be up and that remote files aren't always accessible. Not only can you anticipate it you can ASSUME or rather you SHOULD assume that the db server will be down and that remote files are not accessible. If you on the other hand assume that the db is up and running you are in for a big piece of heart ache when it does go down.

Now I'm not a VB programmer (thank God), but in PHP we have got plenty of tools that allow us to check if a query to a db server executed correctly and if a remote file is readable and/or writable. Defensive programming states that you should check if you can do something before you try to do it.

2006-02-07 Reply Admin

And the WTF still is this god damn post system. When I click "Quote" I assume (wrongfully perhaps) that the quotes will be quoted and not html.

2006-02-07 Reply Admin

Anonymous:
I can imagine his rationale - "well it didn't fall over, so there ARE no bugs!"

That's what debuggers are for. Just run your code through a debugger a couple of
times until all the bugs are removed.

2006-02-07 Reply Admin

At this one place I used to work, I had the following conversation with a, uhm, co-worker, who had messed with my code:

Me: There was a bunch of code here. What did you do to it?
Him: Oh, I didn't know what it did, so I took it out. stares at wall vacantly

That made me a bit miffed.

2006-02-07 Reply Admin

Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

2006-02-07 Reply Admin

Anonymous:
Now that I think about it, isn't this pretty much what C programmers who ignore return codes do? [:$]

Yes... er, I mean, no, never! [:$]

Jeff S · 2006-02-07 Reply Admin

chrismcb:
Jeff S:

good post. However, you can use still "on error resume next" safely and intelligently in good old VB (I used it all the time), as long as you know to use "on error resume 0" immediately after the statement you are trying. This "disables" the "resume next" error handling, and allows you to avoid the goto/resume error handling if you prefer to keep it somewhat sequential in your code. (I actually feel doing it that way is closer to try/catch than the goto/resume method).

Very few people seem to know about "on error resume 0" -- probably because the syntax is so weird and it isn't obvious what the heck it means!

Sure, just like you can use on error goto 0 to remove your exception handler. Except that "on error resume next/statement/on error resume 0" still gobbles the exception. You are disabling the exception handling for that one statement.

It is the equivalent to try { something } catch {}

No. I guess I should have said "immediately after the error check", my bad.

i.e.,

on error resume next
kill "somefile"
if err.number <> 0 then msgbox "Can't do that!"
on error goto 0

StarfishC · 2006-02-07 Reply Admin

Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

2006-02-07 Reply Admin

StarfishC:
Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

I don't get this one. It doesn't parse!

2006-02-07 Reply Admin

StarfishC:
Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

for() goodness sake!

2006-02-07 Reply Admin

Anonymous:
StarfishC:
Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

for() goodness sake!

I can see that this will REPEAT UNTIL someone gets hurt.

2006-02-07 Reply Admin

Anonymous:
Anonymous:
StarfishC:
Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

for() goodness sake!

I can see that this will REPEAT UNTIL someone gets hurt.

do{} your worst!

SeekerDarksteel · 2006-02-07 Reply Admin

Anonymous:
Anonymous:
Anonymous:
StarfishC:
Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

for() goodness sake!

I can see that this will REPEAT UNTIL someone gets hurt.

do{} your worst!

if{} you guys cut this out I'll be happy, else{} I'm gonna have to get angry!

2006-02-07 Reply Admin

Anonymous:

Now that I think about it, isn't this pretty much what C programmers who ignore return codes do? [:$]

Sadly no. A programmer that ignores return codes is being lazy. This guy put in a lot of time and effort into being a tard. He may have even billed overtime for all the work he put in. [:|]

dhromed · 2006-02-07 Reply Admin

SeekerDarksteel:
Anonymous:
Anonymous:
Anonymous:
StarfishC:
Anonymous:
Anonymous:

Do. Or do not. There is no try{}. --Yoda

yeah but there's a catch{} to everything

I hope you guys have finally{} got those awful puns out of your system!

Sorry, they won't be going for a while{}

for() goodness sake!

I can see that this will REPEAT UNTIL someone gets hurt.

do{} your worst!

if{} you guys cut this out I'll be happy, else{} I'm gonna have to get angry!

this.isGetting() ridiculous. I will GOTO try{} && catch(){} the NEXT bus out of here, because this.isDriving() me insane.

LabSpecimen · 2006-02-07 Reply Admin

Anonymous:
Although I'm not really sure what would be the proper tool for fixing this one, fire I would guess.

Thank you. Highlight of my day!

ferrengi · 2006-02-07 Reply Admin

Anonymous:
I SO do not believe this is for real.
This is made up.

Agreed.
How can it be that the guy learned System.Reflection and delegates but is totally clueless on how try-catch is supposed to be used?

Joost_ · 2006-02-07 Reply Admin

cough <FONT size=1>(checked exceptions)</FONT> cough

JohnO · 2006-02-07 Reply Admin

Anonymous:
chrismcb:
IF you don't do this, your program will crash. Letting your program crash is pretty scary and amatuerish. I would want to handle my errors, and not just crash whenever something goes wrong.
No, it isn't. In the face of many errors (and quite potentially the majority) it's the only sane behavior to take, because the error that occurs is inherently unrecoverable.

And if you cannot recover and resume normal operation, then the only correct beavhior is to crash imediately, gracefully (meaning attempt to save work or whatever where possible), and with as much useful information as possible.

I'm glad there's at least one other person in the world that understands this.

2006-02-07 Reply Admin

I hope you all suffer greatly foreach() of these terrible, terrible puns...

The Perils of Error-free Code

Leave a comment on “The Perils of Error-free Code”