The Daily WTF: Curious Perversions in Information Technology

chubertdev · 2013-02-21 Reply Admin

Valued Service:
chubertdev:

I'm out of GAU-8 rounds from the last time I saw developers creating void functions with the prefix "Get", and non-void functions with the prefix "Load."

public static Object XamlReader.Load(Stream stream)

http://msdn.microsoft.com/en-us/library/ms590388.aspx

Time to re'load'

The Load ones weren't as bad. If you have it return a bool to say whether or not the operation was successful, I'm not going to be upset.

But when you prefix a function with "Get", and it doesn't........get, then there are issue. But then again, it was from people who didn't have English as their first language, so I guess the nuances can get lost.

2013-02-21 Reply Admin

operagost:
TGV:
I'd call it the Inception...
THAT'S THE JOKE

I once caught an exception from my realdoll and I can tell you it is no laughing matter.

Nagesh · 2013-02-21 Reply Admin

this code is looking fishy to me. not even junior developer from lowest university will do this thing.

Nagesh · 2013-02-21 Reply Admin

snoofle:
OK, I'm not familiar with this construct... are there always that many inner exceptions?

Will result in endless misery for user.

Nagesh · 2013-02-21 Reply Admin

Pista:
C'mon, this is just plain stupid... This can't exist, it's only the result of someone's imagination.

Agreed with Pista.

2013-02-21 Reply Admin

Nagesh:
I can't believe it's not butter.

throw new NotButterException();

herby · 2013-02-21 Reply Admin

Exceptions are for wimps! Real programmers don't use exceptions, they use setjmp/longjmp. If the exception was bad enough, then 'exit' with a non-zero argument is in order.

We now return you to your regularly scheduled pissing match on the virtues of try/catch of which there aren't many!

2013-02-21 Reply Admin

herby:
Exceptions are for wimps! Real programmers don't use exceptions, they use setjmp/longjmp. If the exception was bad enough, then 'exit' with a non-zero argument is in order.
We now return you to your regularly scheduled pissing match on the virtues of try/catch of which there aren't many!

Virtue #1 Stacktrace.

Oh crap, where did my ERR_FILE_NOT_FOUND occur, I use that in 1,500 places. Ok, time to make 1,500 ERR_FILE_NOT_FOUND_XXX error codes, so I know which one. Wait, I'm starting to clash with the ERR_NEED_NEW_DEV_XXX numbers.

2013-02-21 Reply Admin

Ironside:
operagost:
TGV:
I'd call it the Inception...
THAT'S THE JOKE

I once caught an exception from my realdoll and I can tell you it is no laughing matter.

I once quoted a comment to replay an unrelated meme and I can tell you it was no laughing matter. People are still naught to laugh about it to this day.

2013-02-21 Reply Admin

herby:
Exceptions are for wimps! Real programmers don't use exceptions, they use setjmp/longjmp. If the exception was bad enough, then 'exit' with a non-zero argument is in order.
We now return you to your regularly scheduled pissing match on the virtues of try/catch of which there aren't many!

Yes, because all return objects/values should be wrapped in a checked return object. If only we could get a language to support that without all the boilerplate...

2013-02-21 Reply Admin

lscharen:

Another refactor to prevent Kuli and MiffTheFox from exploding your stack...

catch (Exception ex)
{
    var visited = new HashSet<Exception>();
    while (ex != null && !visited.Contains(ex))
    {
        visited.Add(ex);

        MessageBox.Show(ex.Message);
        ex = ex.InnerException;
    }
}

public class FUException : Exception
{
    private static int i;
    public FUException() { }
    public override Exception InnerExecption { get { return this; } }
    public override bool Equals(object obj) { return false; }
    public override int GetHashCode() { return Interlocked.Increment(i); }
}

2013-02-21 Reply Admin

hashset:

lscharen:

Another refactor to prevent Kuli and MiffTheFox from exploding your stack...

catch (Exception ex)
{
    var visited = new HashSet<Exception>();
    while (ex != null && !visited.Contains(ex))
    {
        visited.Add(ex);

        MessageBox.Show(ex.Message);
        ex = ex.InnerException;
    }
}

public class FUException : Exception
{
    private static int i;
    public FUException() { }
    public override Exception InnerExecption { get { return this; } }
    public override bool Equals(object obj) { return false; }
    public override int GetHashCode() { return Interlocked.Increment(i); }
}

Clever, but won't compile.

2013-02-21 Reply Admin

Exception ex = e.Exception;
while (ex.InnerException != null) {
    MessageBox.Show(ex.Message);
    ex = ex.InnerException;
MessageBox.Show(ex.Message);

The great thing is that it's C# (.NET), so there is no need to free the exception resource! :D

2013-02-21 Reply Admin

I don't think I wanna use GetBaseException()

    public virtual Exception GetBaseException()
    {
      Exception innerException = this.InnerException;
      Exception exception = this;
      for (; innerException != null; innerException = innerException.InnerException)
        exception = innerException;
      return exception;
    }

Captcha: causa: causa the wonderful things it does!

cellocgw · 2013-02-21 Reply Admin

so maybe this function can help (translate to the language of your choice)

function try_me { trycatch(try_me)}

2013-02-21 Reply Admin

Nagesh:
Pista:
C'mon, this is just plain stupid... This can't exist, it's only the result of someone's imagination.
Agreed with Pista.

The only possible explanation is that this shoddy code that was inserted for debugging sake and never removed.

chubertdev · 2013-02-21 Reply Admin

private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
        {
                LibraryThatSomeoneBuiltSoYouDoNotHaveTo.HandleException(e);
        }

2013-02-21 Reply Admin

hashset:

public class FUException : Exception
{
    private static int i;
    public FUException() { }
    public override Exception InnerExecption { get { return this; } }
    public override bool Equals(object obj) { return false; }
    public override int GetHashCode() { return Interlocked.Increment(i); }
}

var visited = new HashSet<Exception>(ReferenceComparer<Exception>.Instance);

ReferenceComparer is trivially implemented.

2013-02-21 Reply Admin

Bring Back TopCod3r:

hashset:

lscharen:

Another refactor to prevent Kuli and MiffTheFox from exploding your stack...

catch (Exception ex)
{
    var visited = new HashSet<Exception>();
    while (ex != null && !visited.Contains(ex))
    {
        visited.Add(ex);

        MessageBox.Show(ex.Message);
        ex = ex.InnerException;
    }
}

public class FUException : Exception
{
    private static int i;
    public FUException() { }
    public override Exception InnerExecption { get { return this; } }
    public override bool Equals(object obj) { return false; }
    public override int GetHashCode() { return Interlocked.Increment(i); }
}

Clever, but won't compile.

    public class FUException : Exception
    {
        private static int i;
        public FUException()
        {
            FieldInfo ha = typeof(Exception).GetField("_innerException", BindingFlags.NonPublic | BindingFlags.Instance);
            ha.SetValue(this, this);
        }
        public override bool Equals(object obj) { return false; }
        public override int GetHashCode() { return Interlocked.Increment(ref i); }
    }

better?

2013-02-21 Reply Admin

The real WTF is that you have a code base where exceptions can be thrown and are never handled more than 1 or 2 layers deep.

icfantv · 2013-02-21 Reply Admin

oh, it's turtles all the way down...

da Doctah · 2013-02-21 Reply Admin

And at the bottom, beneath all the other layer of exceptions, we finally reach the creamy nougat center.

chubertdev · 2013-02-21 Reply Admin

How many licks does it take to get to the center of a DispatcherUnhandledExceptionEventArgs.Exception?

TGV · 2013-02-21 Reply Admin

operagost:
TGV:
I'd call it the Inception...
THAT'S THE JOKE

O fucking hell, it's Remi with his incrowd html comments. Why do I even bother. And his writing...

"Exceptions are a great source of stress and suffering." Is that supposed to be ironic? Except that irony is using language that normally signifies the opposite, and here it doesn't.

"Each exception thrown by our application must be caught handled before the user sees it." Applications rarely throw exceptions. Must be caught handled?

"Failing to do disturbs the balance of our application." Failing to follow errors makes.

"We can use a generic exception handler, but we never can be truly certain we’ve found the true exception." Filler stuff, vaguely philosophically sounding.

"So often the Truth is hidden within an inner exception." And one more.

"It may also be hidden within that exception’s inner exception." He gets to the point, except inner exception doesn't make any sense.

Ok, I'm having a bad hair day...

mthamil · 2013-02-21 Reply Admin

There is the Either monad which can provide a way to deal with this kind of situation. The accepted answer to this question is an explanation using Scala: http://stackoverflow.com/questions/1193333/using-either-to-process-failures-in-scala-code

2013-02-21 Reply Admin

Ommmmmmmmmmmmmm

2013-02-21 Reply Admin

El Fredo:
If you dig deep enough in the exception stack, you end in Limbo.

would we call that Exception?

2013-02-21 Reply Admin

This is brilliant. It gives devs an incentive not to write code that throws exceptions because they have to click through all of the message boxes.

Coyne · 2013-02-21 Reply Admin

XXXXXX:
Like all great exception reporters, he discarded the stack trace and only showed the message.
Thumbs Up Man!

Stack trace? Stack trace? We don't need no steenking stack trace!

Remy Porter:
If we go deep enough, perhaps we will not find an InnerException but inner peace, instead.

Then shouldn't they be referencing property "InnerPeace" in there somewhere?

I agree with the other guy: I think it very likely what they'll actually get is a null reference exception. No inner peace in this monstrosity. Just a sad (and obscure) end.

2013-02-21 Reply Admin

snoofle:
OK, I'm not familiar with this construct... are there always that many inner exceptions?

Nope. That's why it's in a try/catch block!

This will fire off a NullReferenceException in an awful lot of (almost all?) cases, precisely because of that.

chubertdev · 2013-02-21 Reply Admin

NaN (Not a Name):
This is brilliant. It gives devs an incentive not to write code that throws exceptions because they have to click through all of the message boxes.

<sarcasm> Using the app is a task for users! Any good dev doesn't have to use their app, they just develop it. </sarcasm>

2013-02-21 Reply Admin

lscharen:

Tankster:

... must... refactor...

catch (Exception ex)
{
    while (ex != null)
    {
        MessageBox.Show(ex.Message);
        ex = ex.InnerException;
    }
}

Another refactor to prevent Kuli and MiffTheFox from exploding your stack...

catch (Exception ex)
{
    var visited = new HashSet<Exception>();
    while (ex != null && !visited.Contains(ex))
    {
        visited.Add(ex);

        MessageBox.Show(ex.Message);
        ex = ex.InnerException;
    }
}

I propose a change to MiffTheFox's exception.

public class FuckYouException : Exception
{
    public FuckYouException() : base("Yeah well fuck you too!")
    {
    }

    public override Exception InnerExecption
    {
        get { return new FuckYouException(this.Message); }
    }
}

Code untested and might throw an exception when you compile it.

Silverhill · 2013-02-21 Reply Admin

hashset:

public class FUException : Exception
{
    private static int i;
    public FUException() { }
    public override Exception InnerExecption { get { return this; } }
    public override bool Equals(object obj) { return false; }
    public override int GetHashCode() { return Interlocked.Excrement(i); }
}

FTFY. :-p

The Bytemaster · 2013-02-21 Reply Admin

Coyne:

Remy Porter:
If we go deep enough, perhaps we will not find an InnerException but inner peace, instead.
Then shouldn't they be referencing property "InnerPeace" in there somewhere?
I agree with the other guy: I think it very likely what they'll actually get is a null reference exception. No inner peace in this monstrosity. Just a sad (and obscure) end.

I went deep enough in Visual Basic .Net and found... Nothing.

2013-02-21 Reply Admin

Ralph:
Pock Suppet:
MSSQL drivers for Linux
I just threw up in my mouth a little.
This is worse than casting pearls before swine. This is more like sitting down to a fine dinner at a restaurant renowned for its excellence, and mixing in a little diarrhea with the salad dressing, just for added flavor.

I'll leave it to the reader to figure out which end of this interface is the fine food and which part is the diarrhea.

You'd certainly get a code smell ... OTOH in a French restaurant you'd probably spend an inordinate amount of time trying to identify which cheese you'd been served.

2013-02-21 Reply Admin

The Bytemaster:
Coyne:

Remy Porter:
If we go deep enough, perhaps we will not find an InnerException but inner peace, instead.
Then shouldn't they be referencing property "InnerPeace" in there somewhere?
I agree with the other guy: I think it very likely what they'll actually get is a null reference exception. No inner peace in this monstrosity. Just a sad (and obscure) end.

I went deep enough in Visual Basic .Net and found... Nothing.

the amount of exceptional programming puns is just too damn high in this post

chubertdev · 2013-02-21 Reply Admin

The Bytemaster:
Coyne:

Remy Porter:
If we go deep enough, perhaps we will not find an InnerException but inner peace, instead.
Then shouldn't they be referencing property "InnerPeace" in there somewhere?
I agree with the other guy: I think it very likely what they'll actually get is a null reference exception. No inner peace in this monstrosity. Just a sad (and obscure) end.

I went deep enough in Visual Basic .Net and found... Nothing.

You String us along, and leave us Empty...

2013-02-21 Reply Admin

TRWTF is the number of commenters who think infinite loops result in stack overflows.

2013-02-21 Reply Admin

"Of course not," the master replied, "the answer to your question is FIVE TONS OF FLAX"

TRWTF is fnord.

Callin · 2013-02-21 Reply Admin

GOTTA CATCH EM ALL GOTTA CATCH EM ALL

2013-02-21 Reply Admin

oh god, so stupid and short-sighted!

private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
  bool a = true;
  Exception exc = e.Exception;

  while( a )
  {
    try
    {
      exc = exc.InnerException;
    }
    catch(Exception e)
    {
      a = false;
    }
  }

  MessageBox.Show("Innermost exception: " + exc.Message);
}

there. much better!

2013-02-22 Reply Admin

Remy Porter:
In my experience, you never really need to dig more than a level or two down. To have that many nested levels means that you're being super Enterprise-y.

Unless you are trying to use PowerShell to call a DotNET function, and PowerShell doesn't have a formatting wrapper for an exception thrown by that fuction.

For example, if you tying to send an email from a script and use the 'Net.Mail.SmtpClient' class to do it, the true error (couldn't connect to mail server) is three levels down the exception chain from the top error 'reflected function call failed.

2013-02-22 Reply Admin

lscharen:

Another refactor to prevent Kuli and MiffTheFox from exploding your stack...

catch (Exception ex) {
    var visited = new HashSet<Exception>();
    while (ex != null && !visited.Contains(ex))
    {
        visited.Add(ex);

        MessageBox.Show(ex.Message);
        ex = ex.InnerException;
    }
}

Sorry, dude. Unsolvability of the halting problem says you can't win that arms race. (Sorry, I haven't used C# in the better part of a decade, so my syntax may be a bit off, but you should get my point.)

public class FuckYou2Exception : Exception {
    private long n;

    public FuckYou2Exception() : this(0) {}

    public FuckYou2Exception(long n) :
           base("Yeah well fuck you "+new String('u',n)+"!") {
        this.n = n;
    }

    public override Exception InnerExecption {
        get {return new FuckYou2Exception(n+1);}
    }
}

2013-02-22 Reply Admin

C-Derb:
Nagesh:
Pista:
C'mon, this is just plain stupid... This can't exist, it's only the result of someone's imagination.
Agreed with Pista.
The only possible explanation is that this shoddy code that was inserted for debugging sake and never removed.

Winner. That's exactly what happened. I'm the original submitter, and it's code that my coworker checked in (claiming it was inadvertent after the fact) for debugging purposes. For some reason, he couldn't attach the debugger to that process, or it wasn't convenient, so he just threw that code together to give him a message box orgy. Of course, there's a thousand different ways to do it better, but that's what he did.

I assure you, it's very, very real. And from an otherwise competent senior developer to boot.

2013-02-22 Reply Admin

Excelsior:
private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) { ShowException(e.Exception); }
private void ShowException (Exeption myEx) { if (myEx == null) return; MessageBox.Show(myEx.Message); ShowException(myEx.InnerException); }

I made a private ShowException, she made a private ShowInnerException. Then we got caught handled, which sucked.

2013-02-22 Reply Admin

Spewin Coffee:
A more rational approach is to return a structure from all calls that contains a boolean to indicate success or failure of the call. If successful, the data portion contains the returned data. On failure, the data portion contains a human-readable error message, a machine-friendly error code, and optional data.

Yes!

Spewin Coffee:
The programmer is first required to unwrap the result of the call and test for success/failure, which should always be done, but no one does. If the return type enforces checking, the programmer will check it.

YES!

Spewin Coffee:
But the only languages that can handle that sort of return policy natively are weakly-typed languages (e.g. PHP can implement it via arrays).

Uhhhh... wait.

Ok, I was with you 110% up to that point.

This is where a language like (at the risk of coming across as a functional language zealot) Haskell absolutely shines.

Specifically, the [image] Either type does precisely what you suggest. And far from your disclaimer at the end, Haskell is an extremely strongly-typed language, which does require the caller to, as you suggest, "unwrap the result of the call and test for success/failure."

So I'm going to present an example in what is not perfectly idiomatic (or best-practice) Haskell, but I've tried to make it clear to a non-reader.

Assume you have some type called ErrCode - that contains the "machine-friendly error code, and optional data". Other data types I've used should be clear: String, Int and Bool are the obvious things.

Assume further that you have some process called runComputation that takes 3 Ints (call them x[/], [i]y and z) and returns an Int.

Finally you have a couple of functions called sanityCheck1 and sanityCheck2 that each take two Ints and return a Bool. The idea being that for the aforementioned x[/], [i]y and z, sanityCheck1 will evaluate the fitness of y in the context of x, and if that's ok, sanityCheck2 will evaluate the fitness of z in the context of y. You've defined a couple of error codes code_check_1_failed and code_check_2_failed to return in the case of failed checks.

So conceptually we want (using the error-throwing paradigm):

int doThatThing( int x, int y, int z ) throws ErrCode {
    if (! sanityCheck1( x, y )) {
        throw code_check_1_failed;
    }
    if (! sanityCheck2( y, z )) {
        throw code_check_2_failed;
    }
    return runComputation( x, y, z );
}

Fine, now to get rid of the throwing up. In Haskell, we can use Either. Either is parametrized by two further types. We say Either a b (with a and b referring to those parametrized types) - meaning that an instance of Either can be one or the other of Left a or Right b. (I'll get to the Left and Right in a minute.)

In our example, we might want the function doThatThing to return the data type Either (String, ErrCode) Int. This means that the value returned will be one or the other of Left (String, ErrCode) or Right Int.

The Left and Right are "constructors" - basically a token that we can examine. Based on its value (either Left or Right) we can expect the remainder of the return value to contain either an ordered pair of (String, ErrCode) - which is to say, the human and machine readable error codes - or Int - the actual return value of runComputation.

So what does this look like? Here's our doThatThing function again:

doThatThing :: Int -> Int -> Int -> Either (String, ErrCode) Int
doThatThing x y z
    | not (sanityCheck1 x y) = Left  ("Sanity check 1 failed.", code_check_1_failed)
    | not (sanityCheck2 y z) = Left  ("Sanity check 2 failed.", code_check_2_failed)
    | otherwise              = Right (runComputation x y z)

The first line is the type signature - don't worry too much about it.

The rest says that we take in x, y and z, then:

run sanityCheck1 on x and y - if it fails, return Left followed by the pair of human and machine error codes
likewise for sanityCheck2 on y and z
if both of the above succeed ("otherwise"), we call runComputation on x, y and z, then wrap the result up in the Right constructor.

In a real-world usage, of course, runComputation may have its own error codes to potentially return, also wrapped up in an instance of Either. It should go without saying that Haskell has all kinds of facilities to make this trivial to handle.

So now what about the code that calls it? Well, it would look something like the following:

...
case (doThatThing i j k) of
   | Left (str, code) -> putStr str
   | Right answer     -> let x' = answer
in ...

You call doThatThing on some i, j and k. Then test the answer for Left or Right and do an appropriate thing in either case (in this example, copping out by putStr'ing (which does more-or-less the obvious thing) the human error code and stopping, or by saving the computation result in the variable x' and going on).

But you have to do something for both cases. To omit one is a semantic error and will generate a compiler error/warning (depending on settings). Haskell's strong typing gives you this: the entire program is type-checked at compile time, and (at least for types like Either), the compiler knows if there is a case you haven't covered.

Ok, so that was long-winded. And my above disclaimer notwithstanding, I'm really not a functional language zealot. Functional languages are very pretty, but definitely come with their own set of baggage in other areas.

Are there imperative languages with this kind of typing capability? I honestly don't know, but imagine there must be something somewhere. Possibly some hybrid language like [image] Scala might be a promising place to look?

Also Google searches along the lines of "[image] imperative parametric polymorphism" or "[image] imperative hindley milner" may prove fruitful.

Anyway. Yeah. Enough nerding out.

2013-02-22 Reply Admin

XXXXXX:
Like all great exception reporters, he discarded the stack trace and only showed the message.
Thumbs Up Man!

I usually just spit the entire thing out in a message box. Everyone says that's a horrible unprofessional thing to do. Except the users who never complain about it. They just take a screen shot and email it to me. Fifteen lines of soup at least appears more helpful than 'FILE_NOT_FOUND'

I have one application cough Cadence cough Allegro cough PCB Designer cough. It spits out error numbers when things go wrong. Ask support for a list of error codes and what they mean and they'll admit there is no such list. And since it's just a number, they can't help.

2013-02-22 Reply Admin

It works with toiletpaper..

2013-02-22 Reply Admin

right because

int myFunc(char parm1, int parm2, object* returnValue);

is totally impossible to do in C/C++. Where object is of whatever type you want to get back; and the int returned by myFunc is either a Boolean or some error error code value. It works almost the same in Java. Strict typing has nothing to do with it.

The bigger issue comes when you have have to now check all those error results in your code path. If your next action is already conditional your error handling response is any more complex than

if !(myfunc(...)) {exit(1);}

the decision trees get pretty large. Have fun debugging that. Exceptions are useful when used well. That fact that most people don't use them well is not a problem with the syntax or language facility; its a problem with you, me, and anyone else who writes sloppy code out there.

2013-02-22 Reply Admin

private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) { }

Inexception

oh god, so stupid and short-sighted!

Leave a comment on “Inexception”