Comment On Robust Error Handling

I find it hard to believe that this one is from production code. You've got to be kidding.

Obligatory attempt to justify the code:

Perhaps the developer was either:

1) Developing a stub / test function that would be included in one or more classes once tested, and the "Return True" would be replaced by some actual validation code.

2) Developing a virtual function to later be overridden in derived classes.  (can't tell for sure since I don't know if it's possible in VB, what VB version this is, or what the VB Syntax would be)

-blue

 

 

My favorite line of code:

 Dim MESSAGE_ERROR As String = "Cannot return true."

What's wrong with this code?  It looks like good enterprise-quality code to me.  What else is he supposed to do it the function cannot return true?  I suppose some of you would simply trust that the underlying code to execute "Return True" will run without an error.  I, for one, prefer to create solid, robust code, not like other people who just make assumptions about what the compiler will do.

I am absolutely beyond any possible words.  Really.  That's just ... wow. 



So, under what circumstances can a return statement ever throw an exception, exactly?



(Or perhaps to better explain the code, this is a dummy function that
shows how to use whatever system's been created.  Gods, I hope
that's really it.)

Blue:

Obligatory attempt to justify the code:

Perhaps the developer was either:

1) Developing a stub / test function that would be included in one or more classes once tested, and the "Return True" would be replaced by some actual validation code.

2) Developing a virtual function to later be overridden in derived classes.  (can't tell for sure since I don't know if it's possible in VB, what VB version this is, or what the VB Syntax would be)

-blue

It's VB.NET code....and good attempt to justify the code [:)]

Another justification attempt: a lot of companies will require certain error checking in every function, no matter how simple. [^o)]

This just looks like a VB6 programmer who has recently moved to VB.NET.
In VB6, you want to have a higher-level error handler for even the
simplest of methods, because weird things can happen if the state gets
wonky in the code. This reads like a VB6 method re-implemented with
Try/Catch handling.



And if you were ever forced to program in VB6, you would probably be this paranoid too.



It's extra overhead, but I don't really see this as a WTF.

Blue:

1) Developing a stub / test function that would be included in one or more classes once tested, and the "Return True" would be replaced by some actual validation code.

Nope... If that were the case, the MESSAGE_ERROR should have something more meaningful than "Cannot return true."

Blue:

2) Developing a virtual function to later be overridden in derived classes.  (can't tell for sure since I don't know if it's possible in VB, what VB version this is, or what the VB Syntax would be)

VB.Net would be the only one that support exceptions, AFAIK.

And nevertheless, this also doesn't cut it.    The entire function would be overridden, so the exception handling would be lost in the derived class.  The only possible use for this is as a template for how to implement it in a derived class, inwhich case, it deserves a WTF on that level also, since its does a lousy job of that too.

Also, we should remind that (at least in C#, and probably in VB), explicitly re-throwing an exception cause you to lose information (like the line number) of the original exception.  (In C#, to avoid this, you code "throw;" without a parameter.  In VB, the parameter is required, so I don't know how you get around that problem)

a simple ping-type method with the "standard" error handling?

I'd often build distributed systems with a simlpe ping-type method that returned an int because the DB or network went down so frequently that I wanted to see if I could even talk to the server, much less as the DB several states away to do anything.

I think this is proof that people should not eat paint chips, then code.

If a return statement throws an exception, you've got bigger problems, and the exception you wanted to throw the caller probably won't even get back to the caller. Of course, I don't know how hard it is to completely obliterate the stack in the .NET framework, I would imagine that it would be pretty damn difficult.

"Robost Error Handling"

Looks like you could use a more "robost" spell checker.

This must be what happens..  When coding conventions attack!

Alex Papadimoulis:

Private Function CheckOperation() As Boolean

  Dim METHOD_NAME As String = "CheckOperation"

  Dim CODE_ERROR As String = "01"

  Dim MESSAGE_ERROR As String = "Cannot return true."

(snip)

    Dim ed As New ErrorData(CLASS_NAME, METHOD_NAME, CODE_ERROR, MESSAGE_ERROR, ex)

    Dim ce As New ControledError(ed)

    Throw ce

Let's see... use of variables that do not get changed and upper-casing of the names of those variables... Looks like the developer confused constants and variables.

CODE_ERROR is a string, but has a value of 10. This could be justified if the ErrorData constructor takes a string as the second parameter and it could be a non-numeric value somehwere else, but still, seems pretty akward

It looks like ControlledError could use a constructor overload that takes the constructor parameters or Error Data

The dim ce ... throw ce code isn't very useful in this particular case, either.

And the biggist WTF of all: What use is a function that *ALWAYS* returns true? I agree, this could be a function stub, but then the WTF is: why does a stub need such exception handling. Every single way to try to explain this code is a WTF in itself.

That's 5 things I would say WTF at in ONE method that ONLY returns True. That is a BIG WTF!

:

It's extra overhead, but I don't really see this as a WTF.

WTF?!?

Must...resist...urge...to...justify...code...

:

Must...resist...urge...to...justify...code...

Can I make a request? Can we stop the attempts to justify garbage code? I can understand justifying code that actually works and serves a purpose...but c'mon people. It just makes you look bad when you try to justify nonsense.

I dont think this is so bad.  You guys are just VB bashing again.

Even assuming this was an example function to show the underlings how
error checking should be done (and I'm not saying this is a good
example), there's no need for METHOD_NAME as a variable, because you
could easily get that off the stack with a specific function.

getCallingMethodName().



And the perf overhead argument against that fails, because this code
would only run upon exception, which shouldn't happen often, and where
performance doesn't matter.



Definitely a WTF.

god i wish that vbc.exe warned you when it detected unreachable code like some other well-intentioned compilers

Shouldn't happen "often?"



Don't you mean "ever?"

Also, we should remind that (at least in C#, and probably in VB), explicitly re-throwing an exception cause you to lose information (like the line number) of the original exception.  (In C#, to avoid this, you code "throw;" without a parameter.  In VB, the parameter is required, so I don't know how you get around that problem)

Exceptions take an Exception on the constructor which ends up as the Exception.InnerException. throw(new MyException(ex)); is a good way.

As for all those bloody constant declarations. Theres no justification - Exceptions keep track of call stacks and assemblies and so forth. If you are throwing a major exception then your exception class can reflect back on the code in question (this is ok - if its a major problem performance is not an issue) and collect information, or simply bung some state information into it.

An error system I wrote for a absolutely-mission-critical (company had to take insurance out against penalty clauses being invoked in case we stopped the production line - $40000 every 30 secs of downtime - the insurance assessors just about searched every coders anus to make sure we werent going to fuck it up). Anyway. Error logging system serialised the entire control object that threw a serious exception (where possible) and any other relevant data. Then the whole exception object was serialized into sql server with timestamps etc, and a messaging subsystem popped up an alert on all the developers boxes.

Something minor went wrong only twice, but we were able to deserialize the form in a testbench, and then step into it with the debugger ;) It was a heavy solution.

Doesn't this language have stack traces in its exceptions?

Holy WTF! I'm sure there's some way that 'Return True' would generate a very complex error!



Not to mention Throwing another error after doing a catch. Is this a programmatic approach to baseball?

:

What's wrong with this code?  It looks like good
enterprise-quality code to me.  What else is he supposed to do it
the function cannot return true?  I suppose some of you would
simply trust that the underlying code to execute "Return True" will run
without an error.  I, for one, prefer to create solid, robust
code, not like other people who just make assumptions about what the
compiler will do.

If my code doesn't return true after an explicit one-liner 'Return
True' statement, I'll throw out the whole programming language
altogether. And no, so far I've kept good care of my Visual Studio CDs
and docs, thank you.



If you don't trust your compiler, why program high level? Go assemble!

:

I dont think this is so bad.  You guys are just VB bashing again.

I do both VB and C# and I tell you, it definitely does not make sense either way

did you guys notice this?

Catch ex As ControledError
    Throw ex

At least she can create the WTF in few LOC. The other WTFs usually requires us to go through long meaningless LOC.

This makes perfect sense in

http://c2.com/cgi/wiki?TestDrivenProgramming

,well, sorta. It just looks like some existing code was re-tooled poorly.

Way off topic but does anyone else find that the main page to wide for their browser? I generally keep my browser (Opera or Safari) at 850x600 or so on my 1024x768 screen. I'm tired of moving the page left and right to read the text describing the WTF. (Also I use a minimum font size of 10 or 12 pixels.)

Oke , here goes my theory...

the management/boss/someone has a profiler a'la compuware devpartner installed.
which complains on each method that does not have error handling.
so the developers are forced to add idiot error handling to each method to keep from saying "look at this profile report , bad bad coders"

//Roger

[edit]: ...to keep the boss from saying...

KraGiE:

did you guys notice this?

Catch ex As ControledError
    Throw ex

That's right! I can't believe they spelled controlled wrong! WTF!

Why do they need a function that always returns True anyway? The
function shouldn't even exist, let along the error checking, and
definately not the two catches!



On a side now, you can Catch-Throw in VB.NET

Um. At the time I'm writing this there are 32 replies. Only one* of
them points out the redundancy of a function that simply returns True.



[:|]



WTF?



[;)]



* Ok, so now it's 2/33

MikeWoodhouse:

Only one* of them points out the redundancy of a function that simply returns True.

No, two people pointed that out before you :). Okay, so now we are three!

maybe because the others beleve its a stub?
since the method is called "CheckOperation" (and not "ReturnTrue()")
and it also catches a specific exceptiontype that is not present in the code yet..

(Id vote stub if it wasnt for the "can not return true" message , unless thats a joke in the stub)

This is complete crap. In fact I'm sure that someone made this up. I have never met a programmer idiot enough to write this sort of junk. And trust me when I say that I have seen quite a bunch of morons.

Regardless, even if this was a stub function, you would be better off letting any exception propagate, carrying their original (hopefully) meaningful information.

Dim MESSAGE_CAUSE As String = "Must return false."

MikeWoodhouse:

Um. At the time I'm writing this there are 32 replies. Only one* of them points out the redundancy of a function that simply returns True.



WTF?



* Ok, so now it's 2/33

Nah, we just skipped the obvious. Or, it simply was a stub... Which doesn't explain the hideous error handling on the condition that a return statement throws an exception.

 

 

That´s only the beginning, the real WTF starts with the error handling for the catch code.

If the programmer is capable of doing such a WTF with one line ("return true") what will do with de catch?

:

The management/boss/someone has a profiler a'la compuware devpartner installed which complains on each method that does not have error handling so the developers are forced to add idiot error handling to each method to keep from saying "look at this profile report , bad bad coders"

Nope... Does work either.  Why catch two different exceptions?  Why not have the error message say "Useless catch to get by profiling" ?

What would be the best explaination to me, is that originally this function checked something real, and then the situation changed (an external process was eliminated, say), so instead of removing hundreds of calls to CheckOperation(), they simply changed it to return true --- except if you are too lazy to delete the wrap exception handling, why go through the trouble of changing the error message?

 

init6:

Way off topic but does anyone else find that the main page to wide for their browser? I generally keep my browser (Opera or Safari) at 850x600 or so on my 1024x768 screen.

The text formatter for code doesn't word wrap, so if the code example is very wide (often the case in a WTF), it forces the whole block to that width.

Jon Limjap:

wrote:

What's wrong with this code?  It looks like good enterprise-quality code to me.  What else is he supposed to do it the function cannot return true?  I suppose some of you would simply trust that the underlying code to execute "Return True" will run without an error.  I, for one, prefer to create solid, robust code, not like other people who just make assumptions about what the compiler will do.

If my code doesn't return true after an explicit one-liner 'Return
True' statement, I'll throw out the whole programming language
altogether. And no, so far I've kept good care of my Visual Studio CDs
and docs, thank you.



If you don't trust your compiler, why program high level? Go assemble!

I meant to write "I think Jon Limjap missed the joke" but something ate the non-quote section of my post

I say WTF to all of these WTFers that think the code may have some
justification whatsoever.  And, to you VB programmers that wrote
methods to only return true in VB6, please post that code too - so that
we could laugh at it as well.



VB "state wonkiness" could never account for a method as simply
ludicrous as this.  I've seen less overkill in Schwarzenegger
movies!

This is no problem in VB6...

Private Function CheckOperation() As Boolean
  On Error Resume Next
  CheckOperation = True
End Function

 

I see 2 possibilities here:

1) This code was written by a person with "architect" in their job title who is both dyslexic and has ADD.

2)  Written by a template / code generator.  Which would just go to show how much stupider robots are than humans.

I see the real use for this - as an overload for the internal "True" assignment.  What if setting x = True really doesn't set it equal to "true"?  Where's the code coverage on that compiler statement?  Is there error checking in that case?   More objects give us more flexibility.  Yeah.....  That's it.....[:'(]

I have done LOTS of VB.NET.  There is no reason whatsoever for this code, no matter what programming language you use.  So I'm not VB bashing.

That being said, my last job (www.true.com) used all vb.net and had this kind of pointless error catching code all over the place. 

Genius!

:

What's wrong with this code?  It looks like good enterprise-quality code to me.  What else is he supposed to do it the function cannot return true?  I suppose some of you would simply trust that the underlying code to execute "Return True" will run without an error.  I, for one, prefer to create solid, robust code, not like other people who just make assumptions about what the compiler will do.

 

I think it is impossible for "Return True" to create an error.

I mean the function even returns Boolean. If you prefer to create solid robust code then i suggest you study more or something.

Your comment is a WTF to me.