The Daily WTF: Curious Perversions in Information Technology

2014-03-06 Reply Admin

Coyne:
Well of course it's a WTF. He should have written it with a loop:
Collection persons = null;
while (true)
{
   try {
      persons = lookup.getPersonsInformation(loginInfo, department, function);
      break;
   } catch(Exception e) {
      //try, try again
   }
}
return persons;
Recursion isn't the solution for everything!

You forgot Thread.sleep(...) in the catch block. That's much less wtf-y.

captcha: abigo. "I have a head code, abigo."

Smitty · 2014-03-06 Reply Admin

EvilSnack:
Putting on my asbestos suit... Okay.
TRWTF is exceptions, period. I have yet to encounter a situation where exception processing delivers the same level of quality, for the work involved, as a regimen of simply returning an error and then checking the return for errors.

It's true that exceptions provide the flexibility of dealing with errors somewhere other than at the point of the function call, but I have not yet seen a situation where the error was better handled elsewhere. Maybe there is, but in my experience there isn't.

This. I have to help maintain a ludicrously complicated iOS application. The original authors were .NET devs and decided that the .NET exception model should work just fine in Objective-C.

Now we have tons of user-defined NSException subclasses that can boil up from the bowels of the networking layer to be used for logic flow control in the UI. Good times.

Coyne · 2014-03-06 Reply Admin

Anonymous Cowherd:
Coyne:
Well of course it's a WTF. He should have written it with a loop:
Collection persons = null;
while (true)
{
   try {
      persons = lookup.getPersonsInformation(loginInfo, department, function);
      break;
   } catch(Exception e) {
      //try, try again
   }
}
return persons;
Recursion isn't the solution for everything!
You forgot Thread.sleep(...) in the catch block. That's much less wtf-y.

captcha: abigo. "I have a head code, abigo."

By, George, you're right! That does make it much less wtf-y! With a sleep(), this WTF will waste much less CPU time while looping infinitely.

Thanks.

2014-03-06 Reply Admin

If I had to chose, I'd much rather have it fail in seconds whenever there's an error than have it pass when there's a time-sensitive error and fail in minutes for any other kind.

2014-03-06 Reply Admin

This TDWTF really made me chuckle. That and "ben's" comments and those who responded to him.

2014-03-06 Reply Admin

This is not a spam Akismet :)

What does it take to post a url! How I Learned About Exception Handling

ahhh....

2014-03-06 Reply Admin

Hey yelling works :)

2014-03-06 Reply Admin

Sometimes it is really reasonable to just ignore the exception, I did write code that have empty catch block...
To put simply, I need to loop URL that formatted something like http://www.example.com/XXX (XXX=000-999), but some URL simply didn't exist and I don't care. However the library would throw HTTP exception on 404 not found error. Of course I would write an empty catch block...

Then be a dear and leave a comment as to why you're leaving an empty catch block. And be damn sure you're only catching that exact exeption. Which means in the catch block you should be testing the message in the exception to be sure it's a 404 error and not one of the many other possible HTTPExceptions. If it's not the exception you're looking for, then the exception should move along up the stack.

2014-03-06 Reply Admin

It's true that exceptions provide the flexibility of dealing with errors somewhere other than at the point of the function call, but I have not yet seen a situation where the error was better handled elsewhere. Maybe there is, but in my experience there isn't.

Then I suppose it depends on your experience. If you want to have error handling mechanisms being called from all over your code. But the idea behind the exception mechanism seems to be to allow you to have one error handling routine and have it act automatically when an unexpected error occurs. (In a similar idea to security being implemented as a layer on top of the main functionality of the program.)

EvilSnack, you make an interesting point, but it also sounds like you simply haven't had much experience with exceptions to be able to make an informed judgment.

Also, for a properly defined function, the return value should only be of a specific type. This means that if you have error codes in it, then there are some return values that you cannot actually return or everything that may read the return value has to know how to parse the return value for errors. Exception handling prevents you from having to overload your returned type with other meanings.

Gene Wirchenko · 2014-03-06 Reply Admin

faoileag:
EvilSnack:
TRWTF is exceptions, period. I have yet to encounter a situation where exception processing delivers the same level of quality, for the work involved, as a regimen of simply returning an error and then checking the return for errors.
Assuming that in Java you can catch exceptions by their interface, two points come to mind:

With exceptions you can far more easily deal with "families" of errors. With error codes you have to evaluate every single error code and determine what to do with it. With exceptions, this is far easier because you can group them by Interfaces, e.g. ICredentialException, INetworkException etc.

ISTM that you are stuck with those groupings. If all errors come to the same spot, you can group as you wish.

2) If future versions of your code introduce new error conditions, with error codes you will most likely have to update your error handling (unless you just have generic error handling, "if res < 0..."). With exceptions things are a lot easier - as long as you catch by interface, it doesn't matter if the a new version introduces a new exception.
Of course, you could emulate that with returning error objects instead of error codes, but I haven't seen that anywhere yet.

I generally have a global error handler that does minimal cleanup (closing of files, etc.), logs an error, and ends the app.

Where I can deal with specific errors, I set up an error handler, perform the operation that could throw the error, restore the global error handler, then ...

I check through the error codes that can be handled. If the error code is one of those, the corresponding error handling is done. If it is not one of them, there is nothing I can do about so I rethrow the error.

I remember using an encryption library written in Java. It threw lots of things that I had no idea what they were. I had to trap the each of them. I suppose I could have trapped them all in a general catch block, but wouldn't I lose what the error was?

I find try-catch to be very awkward.

Sincerely,

Gene Wirchenko

chubertdev · 2014-03-06 Reply Admin

EvilSnack:
Putting on my asbestos suit... Okay.
TRWTF is exceptions, period. I have yet to encounter a situation where exception processing delivers the same level of quality, for the work involved, as a regimen of simply returning an error and then checking the return for errors.

It's true that exceptions provide the flexibility of dealing with errors somewhere other than at the point of the function call, but I have not yet seen a situation where the error was better handled elsewhere. Maybe there is, but in my experience there isn't.

Switching back and forth between .NET and PHP, I would just like to say that exceptions are approximately ONE_BILLION times better than checking for errors.

2014-03-06 Reply Admin

If at first you don't succeed ...

2014-03-06 Reply Admin

The best part about this is that the inevitable StackOverflowException will be caught, and the recursion will be resumed, causing more SOE even if the getPersonsInformation() call would magically have succeeded on a subsequent call.

chubertdev · 2014-03-06 Reply Admin

Stage Whisper:
Sometimes it is really reasonable to just ignore the exception, I did write code that have empty catch block...
To put simply, I need to loop URL that formatted something like http://www.example.com/XXX (XXX=000-999), but some URL simply didn't exist and I don't care. However the library would throw HTTP exception on 404 not found error. Of course I would write an empty catch block...

Then be a dear and leave a comment as to why you're leaving an empty catch block. And be damn sure you're only catching that exact exeption. Which means in the catch block you should be testing the message in the exception to be sure it's a 404 error and not one of the many other possible HTTPExceptions. If it's not the exception you're looking for, then the exception should move along up the stack.

    public void DoSomethingWithUrl(string url)
    {
        try
        {
            //do stuff with url
        }
        catch (HttpException hex)
        {
            if (hex.GetHttpCode() == 404) { Logger.Log(string.Format("URL not found: {0}", url)); }
            else { throw hex; }
        }
        catch (Exception e)
        {
            //log error, maybe throw it as well depending on what you want the expected behavior of the method to be
        }
    }

no laughing matter · 2014-03-06 Reply Admin

Stage Whisper:
Also, for a properly defined function, the return value should only be of a specific type. This means that if you have error codes in it, then there are some return values that you cannot actually return or everything that may read the return value has to know how to parse the return value for errors. Exception handling prevents you from having to overload your returned type with other meanings.

Use a monad, damnit! And have a look at Haskell, to learn how this can be done in a really elegant way.

2014-03-06 Reply Admin

chubertdev:
Stage Whisper:
Sometimes it is really reasonable to just ignore the exception, I did write code that have empty catch block...
To put simply, I need to loop URL that formatted something like http://www.example.com/XXX (XXX=000-999), but some URL simply didn't exist and I don't care. However the library would throw HTTP exception on 404 not found error. Of course I would write an empty catch block...

Then be a dear and leave a comment as to why you're leaving an empty catch block. And be damn sure you're only catching that exact exeption. Which means in the catch block you should be testing the message in the exception to be sure it's a 404 error and not one of the many other possible HTTPExceptions. If it's not the exception you're looking for, then the exception should move along up the stack.
    public void DoSomethingWithUrl(string url)
    {
        try
        {
            //do stuff with url
        }
        catch (HttpException hex)
        {
            if (hex.GetHttpCode() == 404) { Logger.Log(string.Format("URL not found: {0}", url)); }
            else { throw hex; }
        }
        catch (Exception e)
        {
            //log error, maybe throw it as well depending on what you want the expected behavior of the method to be
        }
    }

else {throw;} - not else {throw hex;}

chubertdev · 2014-03-06 Reply Admin

asdf:
else {throw;} - not else {throw hex;}

Six of one.

2014-03-06 Reply Admin

Why not add a little recursive multi-threading to the mix:

public Collection getPersonsInformation(String department,String function) throws LookupException { ServiceLocator locator = ServiceLocator.getInstance(); LookupInterface lookup = locator.getLookupLocal();

    Collection persons = null;
   
    try {
        persons = lookup.getPersonsInformation(loginInfo, department, function);  
        
    } catch(Exception e) {
          Thread t = new Thread() {
            @Override
            public void run() {
                getPersonsInformation(department,function);
            }
              
          };
          t.start();
          return getPersonsInformation(department,function);

    }
    return persons;
}

2014-03-06 Reply Admin

OK, surely I am missing something. The arity of the calls are different. The first has 3 arguments, the second 2. I am not a Java wrangler but I know it has method overloading. I assume the method that takes 2 arguments returns some default collection not dependent on LoginInfo. The one that takes 3 uses some global LoginInfo that is more specific. I'm guessing LoginInfo has global scope. The RWTF is the global?

2014-03-06 Reply Admin

chubertdev:
asdf:
else {throw;} - not else {throw hex;}

Six of one.

Sure, if you don't care about the whole stack trace and instead want to change where the error came from.

2014-03-06 Reply Admin

Donald Knuth:
OK, surely I am missing something. The arity of the calls are different. The first has 3 arguments, the second 2. I am not a Java wrangler but I know it has method overloading. I assume the method that takes 2 arguments returns some default collection not dependent on LoginInfo. The one that takes 3 uses some global LoginInfo that is more specific. I'm guessing LoginInfo has global scope. The RWTF is the global?

It's not the same method. The one that takes 3 arguments is a method of the LookupInterface object. The one that takes 2 is a public method, which is called from inside of itself.

no laughing matter · 2014-03-06 Reply Admin

Gene Wirchenko:
I remember using an encryption library written in Java. It threw lots of things that I had no idea what they were. I had to trap the each of them. I suppose I could have trapped them all in a general catch block, but wouldn't I lose what the error was?

Huh?

public class Test {
	private static interface Code {
		void run() throws Throwable;
	}
	private static void test(Code c) {
		try { c.run(); }
		catch(Throwable t) { System.out.println("caught " + t); } 
	}
	public static void main(String[] args) {
		test(new Code() { public void run() { int a=1/0; } });
		test(new Code() { public void run() { Integer a=null; a.toString(); } });
		test(new Code() { public void run() { Object a=new Integer(7); String b=(String) a; } });
		test(new Code() { public void run() { Object a=new Integer("Sieben"); } });
		// Checked Exception:
		test(new Code() { public void run() throws MalformedURLException
							{ URL a = new URL("a badly formed URL"); }
						});
}

Needs Lambdas! Returns:

caught java.lang.ArithmeticException: / by zero
caught java.lang.NullPointerException
caught java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
caught java.lang.NumberFormatException: For input string: "Sieben"
caught java.net.MalformedURLException: no protocol: a badly formed URL

But even when the toString() method of the Exception throws away information, you could always call t.getClass().getName(), t.getMessage() / t.getLocalizedMessage() , or whatever else the API provides.

chubertdev · 2014-03-06 Reply Admin

asdf:
chubertdev:
asdf:
else {throw;} - not else {throw hex;}

Six of one.

Sure, if you don't care about the whole stack trace and instead want to change where the error came from.

IMHO, I think that developers have become too dependent on the stack trace for exceptions.

2014-03-06 Reply Admin

Stage Whisper:
It's true that exceptions provide the flexibility of dealing with errors somewhere other than at the point of the function call, but I have not yet seen a situation where the error was better handled elsewhere. Maybe there is, but in my experience there isn't.

Then I suppose it depends on your experience. If you want to have error handling mechanisms being called from all over your code. But the idea behind the exception mechanism seems to be to allow you to have one error handling routine and have it act automatically when an unexpected error occurs.

But usually I want to know exactly where the error occurred. No exception-handling scheme, no matter how cleverly designed, can provide that information with the same amount of work (on my part) as a simple error-handler coded to log the error, right with the function call.

(Ad hominem snipped.)

Also, for a properly defined function, the return value should only be of a specific type. This means that if you have error codes in it, then there are some return values that you cannot actually return or everything that may read the return value has to know how to parse the return value for errors. Exception handling prevents you from having to overload your returned type with other meanings.

...but at the expense of more work to achieve the same result. To be useful the function need only return one result indicating error, with the specifics available by some other means (global variable, system call, etc.). Any other return represents valid data. It's not really more work than an exception, especially if you do it right.

2014-03-06 Reply Admin

I agree. There seems to be a tendency to use exceptions just because they're available. This code should at least die informatively on fatal errors.

2014-03-06 Reply Admin

It's StackOverflowError, so it wouldn't be caught. and that's the reason why catching Throwable is usually a bad idea.

2014-03-06 Reply Admin

Mat:
If at first you don't succeed, try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch.....

FTFY.

2014-03-06 Reply Admin

Mat:
If at first you don't succeed, try try again?

If at frist you don't succeed, try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try try

2014-03-06 Reply Admin

Stargate Fan:
Mat:
If at first you don't succeed, try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch try catch.....

FTFY.

I guess I should have kept on reading past Mat's first post...

2014-03-06 Reply Admin

Ironically, I don't think the programmer found this gem of code on stackoverflow.com.

2014-03-06 Reply Admin

Evan:
The JIT doesn't do it either; the JVM model doesn't make it easy, because a full and correct stack trace has to be available.

That's the same reason Python has resisted implementing tail-recursion too. It's a nice feature for certain cases, but it makes exception reporting vastly more difficult - and oddly enough, most people thing functioning error handling is more important than the rarely-needed ability to implement recursive algorithms...

2014-03-06 Reply Admin

shouldn't the obligitory xkcd link have been obliged by now?

2014-03-06 Reply Admin

Peter Wolff:
Ironically, I don't think the programmer found this gem of code on stackoverflow.com.

Heh... about 6 months ago, I was trying to track down the cause of a StackOverflowError in some third-party code I was using.

Unfortunately, it's now utterly impossible to search for that error... that otherwise useful website just drowns out everything - and you can't easily exclude it from results, because that's where you'd expect to find them...

2014-03-06 Reply Admin

This is the problem with all this new-fangled OO stuff....the more you simplify things, the more simpletons will use it. Unfortunately, I think kids of today don't understand things like exception handling, and are taught to keep things simple - and so why bother catching multiple exceptions explicitly when the language allows you just to catch a generic one?

Also, get off me goddamn lawn!

2014-03-06 Reply Admin

ochrist:
Do or do not. There is no try.
(I guess Yoda wasn't a programmer)

Yoda used Assembler

2014-03-06 Reply Admin

EvilSnack:
Putting on my asbestos suit... Okay.
TRWTF is exceptions, period. I have yet to encounter a situation where exception processing delivers the same level of quality, for the work involved, as a regimen of simply returning an error and then checking the return for errors.

It's true that exceptions provide the flexibility of dealing with errors somewhere other than at the point of the function call, but I have not yet seen a situation where the error was better handled elsewhere. Maybe there is, but in my experience there isn't.

I tend to agree....but then I predominently use languages that haven't really supported exceptions

2014-03-06 Reply Admin

faoileag:
EvilSnack:
TRWTF is exceptions, period. I have yet to encounter a situation where exception processing delivers the same level of quality, for the work involved, as a regimen of simply returning an error and then checking the return for errors.
Assuming that in Java you can catch exceptions by their interface, two points come to mind:

With exceptions you can far more easily deal with "families" of errors. With error codes you have to evaluate every single error code and determine what to do with it. With exceptions, this is far easier because you can group them by Interfaces, e.g. ICredentialException, INetworkException etc.

If future versions of your code introduce new error conditions, with error codes you will most likely have to update your error handling (unless you just have generic error handling, "if res < 0..."). With exceptions things are a lot easier - as long as you catch by interface, it doesn't matter if the a new version introduces a new exception.

Of course, you could emulate that with returning error objects instead of error codes, but I haven't seen that anywhere yet.

OO allows all the interface stuff, which does add your 'families of errors' concept, but that can be easily simulated by things like:

Major and Minor error codes (stroed in an error object if you like)
Grouping Errors eg: 0x0000 = no error, 0x0001 to 0x000F are network errors, 0x0010 - 0x001F are someit else errors, etc
etc

I can sort of imagine advantages to an exception based approach, but I can also think of advantages to an error-code based approach (and let's remember not all languages are OO....).

Then again, when all you have is a hammer.....

2014-03-06 Reply Admin

S:
Evan:
The JIT doesn't do it either; the JVM model doesn't make it easy, because a full and correct stack trace has to be available.

That's the same reason Python has resisted implementing tail-recursion too. It's a nice feature for certain cases, but it makes exception reporting vastly more difficult - and oddly enough, most people thing functioning error handling is more important than the rarely-needed ability to implement recursive algorithms...

I put it to you, Your Honour, that lots of people think thatg functioning error handling is more important than minimising the likelihood of errors in the first place.....

2014-03-06 Reply Admin

Dave:
ben:
I dont understand where the recursion is and what the problem is: getPersonsInformation and lookup.getPersonsInformation can surely be different methods.

The recursion is in the catch part of the exception handler. It calls itself with the attributes it was passed.

No, the method signature in the catch block is different. The method called in the catch block has one argument. The overall method has two arguments. For all we know, the method being called does not recurse.

HardwareGeek · 2014-03-06 Reply Admin

cowardly man:
No, the method signature in the catch block is different. The method called in the catch block has one argument. The overall method has two arguments. For all we know, the method being called does not recurse.

No, the method called in the catch block has two arguments, department and function, exactly the arguments it was originally called with. At least in the OP; maybe you're looking at a commenter's modification that messed that up. (I didn't notice any such goof, but it's possible.)

2014-03-06 Reply Admin

Exceptional trampolining using anonymous classes? Eww. Java sucks!

2014-03-06 Reply Admin

anonymous:
Sometimes it is really reasonable to just ignore the exception, I did write code that have empty catch block...
To put simply, I need to loop URL that formatted something like http://www.example.com/XXX (XXX=000-999), but some URL simply didn't exist and I don't care. However the library would throw HTTP exception on 404 not found error. Of course I would write an empty catch block...

404? You don't need an exception for file not found. Just use a Boolean.

2014-03-06 Reply Admin

Mat:
If at first you don't succeed, try try again?

I was thinking the same, but the code doesn't do that. Here's what it would have to do:

public Collection getPersonsInformation(String department,String function) throws LookupException {
	  ServiceLocator locator = ServiceLocator.getInstance();
	  LookupInterface lookup = locator.getLookupLocal();
	  Collection persons = null;
	  try {
		  persons = lookup.getPersonsInformation(loginInfo, department, function);	
	  } catch(Exception e) {
			getPersonsInformation(department,function);
			return getPersonsInformation(department,function);
	  }
	  return persons;
}

2014-03-06 Reply Admin

Mick:
I put it to you, Your Honour, that lots of people think thatg functioning error handling is more important than minimising the likelihood of errors in the first place.....

Errors will happen, no matter how much you minimise the likelihood, and when they do, the language needs to make it easy to find them. And while tail-recursion is a useful feature, it's not going to make any great difference in reducing the frequency of errors.

2014-03-06 Reply Admin

S:
Mick:
I put it to you, Your Honour, that lots of people think thatg functioning error handling is more important than minimising the likelihood of errors in the first place.....

Errors will happen, no matter how much you minimise the likelihood, and when they do, the language needs to make it easy to find them. And while tail-recursion is a useful feature, it's not going to make any great difference in reducing the frequency of errors.

errors will happen, and you need to handle them. Granted. But that doens't make excpetion handling more important than avoiding errors/exception.

2014-03-06 Reply Admin

Smitty:
This. I have to help maintain a ludicrously complicated iOS application. The original authors were .NET devs and decided that the .NET exception model should work just fine in Objective-C.
Now we have tons of user-defined NSException subclasses that can boil up from the bowels of the networking layer to be used for logic flow control in the UI. Good times.

I feel sorry for you. (For those who don't know: In Objective-C, an exception means "the programmer made an error". You don't catch exceptions, you fix the code. Works very well. )

2014-03-06 Reply Admin

actually the StackOverflow in java is an Error; though an error is a throwable, it is not an exception, and would therefore not be caught. ...and it would be difficult to handle that one anyhow, but different discussion

Coyne · 2014-03-06 Reply Admin

Gene Wirchenko:
I remember using an encryption library written in Java. It threw lots of things that I had no idea what they were. I had to trap the each of them. I suppose I could have trapped them all in a general catch block, but wouldn't I lose what the error was?

To keep from losing the error information, "convert" the exception to a RuntimeException (those don't have to be declared in the method header). Example:

   try { encryptionMethod(); }
   catch (InterestingException e) { fixInterestingException(); }
   catch (Exception e) { throw new RuntimeException(e); }

The last "catch (Exception e)" catches any type of Exception you didn't already catch. Then that Exception is passed into a new RuntimeException and thrown again.

When the program fails (from the thrown RuntimeException) you still get the full information set, which will read something like, "Here are the details of your RuntimeException, which occurred (here) and was caused by another (Exception e) which occurred (there)." The complete report contains everything you need to know.

There are a couple of other ways you could save the information, but this is best: you might want to know where to add another catch, for example.

2014-03-06 Reply Admin

no laughing matter:
Stage Whisper:
Also, for a properly defined function, the return value should only be of a specific type. This means that if you have error codes in it, then there are some return values that you cannot actually return or everything that may read the return value has to know how to parse the return value for errors. Exception handling prevents you from having to overload your returned type with other meanings.
Use a monad, damnit! And have a look at Haskell, to learn how this can be done in a really elegant way.

I forgot to mention that that particular library (actually, it's pywikipedia) have its own exception class for page not found error (pywikipedia.NoPage), so I just catch NoPage exception and ignore it :)

2014-03-07 Reply Admin

chubertdev:
asdf:
chubertdev:
asdf:
else {throw;} - not else {throw hex;}

Six of one.

Sure, if you don't care about the whole stack trace and instead want to change where the error came from.

IMHO, I think that developers have become too dependent on the stack trace for exceptions.

That's like what one lungfish says to another lungfish: "IMHO, I think that land-dwellers have become too dependent upon legs for locomotion."

Exceptional Recursion

Leave a comment on “Exceptional Recursion”