www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - catch without block/scope brackets

reply Jakob <a b.com> writes:
While this works:

	try
		foo();
	catch {
		fwritefln(stderr, "Can't do that");
	}

This doesn't:

	try
		foo();
	catch
		fwritefln(stderr, "Can't do that");

Giving the errors:

found 'fwritefln' when expecting '('
basic type expected, not (

And so on.


IMHO, the compiler should parse the second piece of code in the same manner as
the first piece, since there are (as in the first example) no brackets after
the catch keyword defining an object to catch. Right?

I'm using GDC 0.24 on Linux, and i don't know if this is also happening in DMD.
Sep 04 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jakob" <a b.com> wrote in message news:fbjmcu$68k$2 digitalmars.com...
 IMHO, the compiler should parse the second piece of code in the same 
 manner as the first piece, since there are (as in the first example) no 
 brackets after the catch keyword defining an object to catch. Right?

I've thought about this as well, and I think it's because allowing a statement without braces there would introduce an ambiguity: try foo(); catch (bar).baz(); Parenthesized expressions are allowed to come at the beginning of expressions, and therefore at the beginning of statements. So the compiler would parse the catch block in this case as "catch(bar", thinking that "bar" is the type of a catch specialization, and then expect an identifier after "bar". Thankfully there's no ambiguity when you _do_ specify an exception specialization: try foo(); catch(Object ex) fwritefln(stderr, "An error happened. %s", ex.toString());
Sep 04 2007
next sibling parent reply Jakob <a b.com> writes:
Jarrett Billingsley schrieb:
 "Jakob" <a b.com> wrote in message news:fbjmcu$68k$2 digitalmars.com...
 IMHO, the compiler should parse the second piece of code in the same 
 manner as the first piece, since there are (as in the first example) no 
 brackets after the catch keyword defining an object to catch. Right?

I've thought about this as well, and I think it's because allowing a statement without braces there would introduce an ambiguity: try foo(); catch (bar).baz(); Parenthesized expressions are allowed to come at the beginning of expressions, and therefore at the beginning of statements. So the compiler would parse the catch block in this case as "catch(bar", thinking that "bar" is the type of a catch specialization, and then expect an identifier after "bar".

Well, that makes sense. But i also tried catch() foo(); and it errored, even though this wouldn't be ambigous
 
 Thankfully there's no ambiguity when you _do_ specify an exception 
 specialization:
 
 try
     foo();
 catch(Object ex)
     fwritefln(stderr, "An error happened. %s", ex.toString()); 
 
 

Yeah, but i didn't use the exception-object and thought, it's stupid to declare a variable and then not use it.
Sep 04 2007
next sibling parent reply mwarning <mw nospam.xy> writes:
Jakob Wrote:
 But i also tried
 
 catch()
 	foo();
 
 and it errored, even though this wouldn't be ambigous
 

to avoid a potential ambiguity.
Sep 04 2007
parent Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

mwarning wrote:
 Jakob Wrote:
 But i also tried

 catch()
 	foo();

 and it errored, even though this wouldn't be ambigous

to avoid a potential ambiguity.

http://digitalmars.com/d/1.0/statement.html, TryStatement, under LastCatch. Allow me to quote: Catches: LastCatch Catch Catch Catches LastCatch: catch NoScopeNonEmptyStatement Looks like a bug. --downs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3mBYpEPJRr05fBERAhuCAJ9Lphr42id09APcTA+dT67h09uytQCgpDz1 xMTRqN2sFmtOFR9z/wOu5Js= =a3WN -----END PGP SIGNATURE-----
Sep 05 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jakob" <a b.com> wrote in message news:fbjrlj$h0q$1 digitalmars.com...
 catch()
 foo();

That looks like a nice compromise.
Sep 04 2007
prev sibling parent reply Downs <default_357-line yahoo.de> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley wrote:
 I've thought about this as well, and I think it's because allowing a 
 statement without braces there would introduce an ambiguity:
 
 try
     foo();
 catch
     (bar).baz();
 

catch statement anyway, since the type is woefully missing. If we add a type, as in catch (Exception bar), the second case, (Exception bar).baz() ceases to be a valid statement. I'm probably missing something. Could you explain, please? --downs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3mEjpEPJRr05fBERAtZAAJwKc5xGzVYWh2WtejwV/7pwSezO+QCgi8fF WM4EUfUstZ+0cvbGSWHU9Ww= =v/zf -----END PGP SIGNATURE-----
Sep 05 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Downs" <default_357-line yahoo.de> wrote in message 
news:fblngc$egs$2 digitalmars.com...
 I don't think this is an ambiguity. After all, catch(bar) is not a valid
 catch statement anyway, since the type is woefully missing.

I'm not saying catch(bar) _is_ valid, I'm saying that the compiler goes "oo, catch! then lparen! there must be a type and then an identifier next." Then it tries to parse a type and an identifier, but that fails. I suppose it's not an ambiguity in the simple sense (two possible valid parse trees), but more like.. given the sequence of tokens, there's no way for the compiler to know what's next. It's ambiguous, but one parse tree is valid and the other is not. Having the compiler explicitly deal with these kinds of nasty issues ends up with a far more complex (and slower) compiler than simply having the grammar disallow them in the first place, like what's been done here.
Sep 05 2007