Forcing Exception Catching At Compile Time

[Bryan Bullard]

hi,

is there a way to force the user of an object to catch exceptions of
specific type?

for instance a compile error is issued if exception 'ExeceptionXXX' thrown
by method 'ThrowsExceptionXXX' is not caught.


thanks,
bryan

 

[Ron Natalie]

hi,

is there a way to force the user of an object to catch exceptions of
specific type?

for instance a compile error is issued if exception 'ExeceptionXXX' thrown
by method 'ThrowsExceptionXXX' is not caught.

No way to do that. Exceptions need not be caught in the function
that throws them, or even one level up (if that were the case, they'd
have little purpose, you'd just return instead).

 

[Bryan Bullard]

ron-

no, not in the function that throws them. i'm not sure if my question was
clear.

i want to know if there is a way to force the compiler to check to see if an
exception is throwable by the method in question. if a call to that method
is not in a try/catch block a compile time error is produced.

similar to java.

thanks,
bryan

 

[Donovan Rebbechi]

ron-

no, not in the function that throws them. i'm not sure if my question was
clear.

i want to know if there is a way to force the compiler to check to see if an
exception is throwable by the method in question. if a call to that method
is not in a try/catch block a compile time error is produced.

similar to java.

C++ does not have checked exceptions. It has "exception specifications", which
are not the same thing. You can google on this topic if you like. There's a
widespread feeling in the C++ community that exception specifications, as implemented
in C++, are not very helpful.

Cheers,

 

[Bryan Bullard]

thanks for your post.

-bryan

C++ does not have checked exceptions. It has "exception specifications", which
are not the same thing. You can google on this topic if you like. There's a
widespread feeling in the C++ community that exception specifications, as implemented
in C++, are not very helpful.

Cheers,

 

[Ron Natalie]

ron-

no, not in the function that throws them. i'm not sure if my question was
clear.

i want to know if there is a way to force the compiler to check to see if an
exception is throwable by the method in question. if a call to that method
is not in a try/catch block a compile time error is produced.

But how is it supposed to do that? The try/catch block may be some
distance up the call stack and perhaps in a completely different translation
unit.

a.cc
int main() {
void foo();
try { foo(); } catch { exit(1); }
}

b.cc
void goo() {
throw "BLETCH";
};

void foo() {
goo();
}

So when the compiler calls b.c it's supposed to complain that foo() doesn't
catch the exepction? It is caught, but in another tu.

 

[Donovan Rebbechi]

But how is it supposed to do that?

The point is that you combine it with something similar to exception
specifications: you either need to specificy that the function throws
the given exception, or you need to catch it.

The try/catch block may be some
distance up the call stack and perhaps in a completely different translation
unit.

the caller of the function that issues the throw statement needs to either
catch the exception or include a specification in its declaration.

the caller of a function that includes such a specification needs to do
the same (use a try/catch or an exception specification).

The up-the-stack thing follows by induction.

a.cc
int main() {
void foo();

should be (in this way of looking at things, which doesn't work in C++):
void foo () throw (const char*);

I'm not sure why C++ doesn't have specifications implemented in this
manner.

Cheers,

 

[Bryan Bullard]

But how is it supposed to do that? The try/catch block may be some
distance up the call stack and perhaps in a completely different translation
unit.

which is fine if all the headers are there and there was support for it in
the language. a method would have to be declared to thrown an exception of
a certain type.

a.cc
int main() {
void foo();
try { foo(); } catch { exit(1); }
}

just as mr. rebbechi mentioned, c++ don't support exception checking.
in an exception checking scenario, the compiler would give an error if foo
is not called in a try block that catches char* or something more generic
(...) if goo or foo is declared to throw char* (or "BLETCH" as you say)

-bryan

 

[Ron Natalie]

the caller of the function that issues the throw statement needs to either
catch the exception or include a specification in its declaration.

Why. By not having an exception specification, the function is free to throw
any exception.

I'm not sure why C++ doesn't have specifications implemented in this
manner.

Because the compiler is a little prejudiced against enforcing things across
translation units.

 

[Bryan Bullard]

Why. By not having an exception specification, the function is free to throw
any exception.

can you not see the inherent problem of that? how do i know what might be
thrown?

Because the compiler is a little prejudiced against enforcing things across
translation units.

what do you call type safety?

 

[Ron Natalie]

can you not see the inherent problem of that? how do i know what might be
thrown?

You don't.

what do you call type safety?

Which is not enforced across translation units. You only get type safety because
the declarations are included in each unit. C++ has a giant cop out called the ODR
that says you'd better be damn sure everything matches in different TU's.

 

[Alexander Terekhov]

Bryan Bullard wrote:
[...]

how do i know what might be thrown?

And what makes you think that you know it in Java? All java methods
have implicit "throws RuntimeException, Error" clause (you just can't
have C++-like throw()-nothing things) and Java runtime/VM can "inject"
unchecked exceptions anywhere at any time.

regards,
alexander.

 

[Donovan Rebbechi]

Why. By not having an exception specification, the function is free to throw
any exception.

I don't understand what your point is.

I think that when you specify throw (Foo) in java, you're only making a
guarantee about checked exceptions (you can still throw any unchecked
exception)

Because the compiler is a little prejudiced against enforcing things across
translation units.

It doesn't need anything to be enforced across translation units. The following need
to be enforced:

(1) if a function uses the throw () keyword to throw a checked exception, it must
either (a) use an exception specification, or (b) a try/catch block

(2) the caller of a function that is declared with an exception specification is
required to either (a) specify the same exception , or (b) use a try/catch block
to catch it in that stack frame.

None of this requires anything to be enforced across translation units. The point is
that the declaration (but not necessarily the definition) of the callee appears in
the translation unit that calls it, and if the callee did not use a catch block, the
declaration includes an exception specification. So the caller's translation unit
is free to remain blissfully ignorant about the callees translation unit.

Of course you have various issues that arise when the function is declared with
different exception specifications in the different translation units. In that case,
you either need exception specs in the ABI, or you need to (in the true spirit
of C++) yell "Ouch! Don't do that!"

Cheers,

 

[Ron Natalie]

I think that when you specify throw (Foo) in java, you're only making a
guarantee about checked exceptions (you can still throw any unchecked
exception)

If the function has an exception specification, all other exceptions cause an
unexpected() invocation.

It doesn't need anything to be enforced across translation units. The following need
to be enforced:

That would work if it weren't for the fact that functions without exception specifications
exist that mean *ANY EXCEPTION MAY OCCUR*. Unfortunately most of the
standard library functions are declared this way. To fix the standard library (especially
for things like containers) you'd need to require that the objects that could be stored in
them play this game as well.

We're paying the price for the fact that exceptions were an afterthought to the language.

 

[Bryan Bullard]

You don't.

exactly.

Which is not enforced across translation units. You only get type safety because
the declarations are included in each unit. C++ has a giant cop out called the ODR
that says you'd better be damn sure everything matches in different TU's.

that sounds like a linking issue. not a compiler/language issue.

 

[Bryan Bullard]

lets please not make this into a java/c++ comparison.

Bryan Bullard wrote:
[...]

how do i know what might be thrown?

And what makes you think that you know it in Java? All java methods
have implicit "throws RuntimeException, Error" clause (you just can't
have C++-like throw()-nothing things) and Java runtime/VM can "inject"
unchecked exceptions anywhere at any time.

in java one knows what will be thrown implements a throwable interface.
as opposed to character pointer, integer, or (...)

however, please note to original question of this post.

 

[Alexander Terekhov]

Bryan Bullard wrote:
[...]

however, please note to original question of this post.

http://groups.google.com/[email protected]

regards,
alexander.

 

[Donovan Rebbechi]

If the function has an exception specification, all other exceptions cause an
unexpected() invocation.

Yep, I'm familiar with what C++ does, more so than I am with Java. I actually
ran into checked exceptions in java by accident, when I had to modify some
java code that used them. I don't know how useful they are(n't).

That would work if it weren't for the fact that functions without exception
specifications exist that mean *ANY EXCEPTION MAY OCCUR*. Unfortunately
most of the standard library functions are declared this way. To fix the
standard library (especially for things like containers) you'd need to
require that the objects that could be stored in them play this game as well.

I take it you're suggesting that a compile-time checked nothrow (for example)
would be useful but not practical given the current state of affairs ? I
certainly agree with that. (Checked exceptions of course do not give you a
compile time checked nothrow)

Cheers,