Discuss
  • try without catch or finally

try without catch or finally

# Jussi Kalliokoski (13 years ago)

I'm not sure if this has been discussed before, but is it a terribly bad idea to make catch/finally optional for a try block?

There's a lot of code like this out there:

try { /* something here / } catch (e) { / nothing here */ }

# Nebojša Ćirić (13 years ago)

It's easy to forget to catch in cases you wanted to.

Maybe adding a new keyword:

try { ... } drop;

  1. април 2012. 13.35, Jussi Kalliokoski <jussi.kalliokoski at gmail.com> је написао/ла:
# Domenic Denicola (13 years ago)

Tangentially related: kriskowal/q/wiki/On

# Jussi Kalliokoski (13 years ago)

I don't think it's really necessary to have another keyword for that just so you wouldn't forget the catch, sounds more like work for a static code analysis tool to me, just like we don't want if (something) doSomething() to throw just because you might have forgotten the curly braces.

P.S. Sorry Nebojša for double posting, I always forget reply all! ;)

# Andreas Rossberg (13 years ago)

On 17 April 2012 22:35, Jussi Kalliokoski <jussi.kalliokoski at gmail.com> wrote:

I'm not sure if this has been discussed before, but is it a terribly bad idea to make catch/finally optional for a try block?

There's a lot of code like this out there:

try { /* something here / } catch (e) { / nothing here */ }

Silent catch-alls like that are almost always bad code. I think the language rather shouldn't encourage this pattern with extra convenience.

# Jussi Kalliokoski (13 years ago)

Silent catch-alls like that are almost always bad code. I think the language rather shouldn't encourage this pattern with extra convenience.

I don't see how this would be much more encouraging than allowing for the catch block to do nothing. The people who would use this would leave the catch block empty anyway.

I am also perplexed as to how often things are countered with similar arguments. Incompetent programmers make bad decisions regardless of how much the language/framework/library does to prevent this. In my mind it's not a valid excuse for not making things harder for those who know what they're doing. (And I'm in no way claiming to be a competent developer, this is just an opinion :])

# Michael A. Smith (13 years ago)

Why is the argument and curly brace syntax required for except? Why not simply allow:

try { throw ExceptionalException; } catch dosubroutine();

which for the convenience of Jussi's original ask:

try { //fail } catch null;

(or if you prefer, a noop call). The lack of parentheses make it clear that the word following 'except' is not the error parameter, and the lack of braces clearly means the catch-phrase ends at the semicolon. It could even be immediately followed by a finally, which I think yields some terse, but useful syntax that's intuitive and consistent.

try foo(); catch bar(); finally cleanUp();

in the same spirit as

if (foo) doFoo(); else doBar();

-Michael A. Smith