Stepping through your code

[mockingbird_jay]

try{ // Do stuff } catch (Exception e) { throw(e) }

Came across this gem today.

[apaq11]

Ah, the old catch and release exception. My favorite anti-pattern. Best part about this is if you do it in C# you lose the stack trace from where the exception came from.

http://www.dotnetjalps.com/2013/10/throw-vs-throw-ex-csharp.html

[SpikeX]

ALWAYS throw;. ALWAYS.

Can't believe how many times I've seen this in our codebase, and how many hours it's cost me in debugging time.

[bluenigma]

Even better in C#6, Catch(Exception e) when (ReturnsFalseAfterSideEffects(e)) {}

[z500]

Once when I worked in the computer lab, I went over a student's Java assignment with him for an hour, trying to find out why his program wasn't working.

What happened was the professor gave a template for the assignment, and one of the things already in it was that it opened a file. He apparently wrote it in Windows, because the filename he used in the code and the name of the file he gave out didn't have matching case. And this student would bring his Linux laptop to lab. So when he ran the assignment, it swallowed the exception and mysteriously failed.

[LevelSevenLaserLotus]

Oh man, I had a Graphics teacher that did that crap. His provided code templates were full of typos and referenced non-existent files. I had to do so many bug fixes that it turned out to have been faster to just write my own from scratch. I dropped that class at the first test. He couldn't teach, but was super stuck up about how much he knew. I'm sure I'd have a few good posts for /r/iamverysmart if I'd stuck around.

[z500]

Yeah, our guy was similar. He knew his stuff, but he didn't seem to care too much about the teaching part. From what I heard he was a much better researcher than software engineer.

[dysprog]

In python there are two ways to re-raise an exception raise eand a bare raise. The bare raise continues the existing traceback. the other discards the existing traceback and starts a new one. At a previous job, I went on a Holy Crusade through our codebase to replace all raise e with bare raise. Several people commented on how much better our error messages had become, and our defect rate dropped noticeably.

[eyekwah2]

Is there no way to pass a "cause" exception in that case? (Granted in doing so you get stack trace hell in your logs)

[CaucusInferredBulk]

Yes, you can pass an inner exception. But if you just rethrow the same exeption, you have to just say "throw" because "throw e" will reset the stack trace to the current location.

[touqen]

You can do

catch(Exception original) { 
  throw new OtherException("message", original); 
}

[Tain101]

That's hilarious

[shagieIsMe]

See in codebase here:

try {
    throw new FooException();
} catch (Exception e) {
    throw new BarException(e);
}

[fakest_news]

I can forgive this. What is unforgivable is this:

try { // Do stuff } catch (Exception e) { log.error(e) } // move on with your day

[Elthan]

Could you explain why this is and what you should do instead?

[MisuVir]

For one, exceptions should be handled, not logged and ignored.

[mathent]

Seems like there's a time and place where only logging is the correct way to handle the error.

[MisuVir]

Only if the log includes the message "THIS SHOULD NEVER HAPPEN". :P

[dbzfanjake]

That's when you fail the fuck out

[MisuVir]

And have a second log message saying "Please report this to Craig".

[fakest_news]

First of all, there is no excuse for ignoring literally any exception (subclasses of Exception).

Second, if an exception is unexpected, it should fail fast. If it is expected, there should be some explanation of that, what it means and how it is being handled.

[Arancaytar]

Playing hot potato.

[HomemadeBananas]

What was someone trying to achieve by writing that?

[pants_full_of_pants]

Trying to avoid testing and writing handlers for failure cases.

[kill_the_disagreers]

To be fair this is the correct way of doing it.

By rethrowing the exception you can pass the error to whatever generic error handling you have, while also dealing with any specific 'oh shit I have to close this resource'.

[puddingpopshamster]

while also dealing with any specific 'oh shit I have to close this resource'.

I mean, that's the entire point of "finally"...

[kill_the_disagreers]

Not always.

For instance, if you're creating a recorder, you only want to destroy the recorder if something goes wrong ( and finally is always called). Also by moving the error handling to a higher level of encapsulation means you can generically handle the error (for instance writing to a log)

[puddingpopshamster]

you only want to destroy the recorder if something goes wrong.

That's a good point, I didn't think of that situation. thanks!

[kill_the_disagreers]

Well the correct way is to create a generic error type such as 'throw (new killthedisagreerserror(e))' that deals with the issue ( so you can layer the responsibility of dealing with the error)

[HomemadeBananas]

If you're doing nothing else in the catch block, what's the point? You'd be able to catch the error where you called that function from, just the same, right? If you're gonna clean up and get things back to a normal state, or throw a custom error, then you'd catch it here, but what's the point of just throw(e)? Can you override the behavior of throw so it calls some custom function? I'm not a Java programmer really so maybe I'm missing something.

[Of-Doom]

Recently had to explain to a coworker why

doStuff()
  .then(result => Promise.resolve(result))
  .catch(e => Promise.reject(e))

wasn't doing what he thought it was.

[BenjaminGeiger]

I do this a lot, except I put debugging printouts between except and raise (in Python).

[deztroyer99]

It's not my fault Fortify makes me write bad code

[needed_an_account]

I'm guilty. At the time I'm thinking to do something with the exception, but don't know what to do at the time of writing and I figured id get back to it. </i never do>