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
 


I guess it was a decision to not allow catch without curly brackets at all
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


 I guess it was a decision to not allow catch without curly brackets at all
 to avoid a potential ambiguity.


That's odd, because that kind of catch is in the spec.
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();
 


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. 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