On 2004-08-20 23:05, llewelly wrote:
> usenet-nospam@nmhq.net (Niklas Matthies) writes:
:
>>> In my opinion, exceptions thrown by dependent operations are not the
>>>     responsibility of the template's definition, and therefor, the
>>>     implementor should have no such desire.
>>
>> The fact that the caller might not be able to detect whether an
>> exception comes from a dependent operation or from a non-dependent
>> operation (because both may throw exceptions of the same type) could
>> be a reason to wrap exceptions thrown by dependent operations into
>> a dedicated type.
:
> To me, wrapping the exception is a work around; a kind of information
>     clouding which requires extra work at both ends. (I note that it
>     is less work in Java, however.)

To me it is a way to make sure that at the receiving end the code can
tell with certainty where the exception came from, without having to
rely on assumptions about the implementation of the outer function
(and also without having to depend on the set of exception types
thrown by the inner function).

Note that the fact that an exception has been wrapped matters only
if you need to catch it by type to distinguish it from other
exceptions. It has been argued that this should be rarely needed
anyway, from which it would follow that the extra work of unwrapping
exceptions should only be needed rarely as well.

Of course, if the language could be made aware of exception chaining,
it would be quite straightforward to augment catch() to be able to
catch exceptions of a certain type anywhere in the chain of exception
objects being thrown, so the extra work would pretty much disappear
(at the source code level, that is).

>> [1]
>> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Method.html
>
> You mean this part?
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Method.html#invoke(java.lang.Object,%20java.lang.Object[])
> http://xrl.us/cr57

Yes. The anchor (part of the URL starting with #) doesn't properly
work in some (many?) browsers due to the space character, so I
preferred to just provide the page URL.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

usenet-nospam@nmhq.net (Niklas Matthies) writes:

> On 2004-08-16 16:34, llewelly wrote:
>> usenet-nospam@nmhq.net (Niklas Matthies) writes:
> :
>> In my opinion, exceptions thrown by dependent operations are not the
>>     responsibility of the template's definition, and therefor, the
>>     implementor should have no such desire.
>
> The fact that the caller might not be able to detect whether an
> exception comes from a dependent operation or from a non-dependent
> operation (because both may throw exceptions of the same type) could
> be a reason to wrap exceptions thrown by dependent operations into
> a dedicated type.
>
> More generally put, I don't see a great difference between templates
> invoking dependent operations and functions performing callbacks on
> function pointers or functor objects, or even just virtual member
> functions.

I agree that there is little difference between these two
    cases. However I think that in both cases, exceptions thrown by
    by functions specified by the user - wether via template depenent
    names or pointers to functions - are the responsibility of the
    function which uses the depenent names or user specified
    functions.

> In either case the exceptions thrown by the inner operation
> may be unknown to the immediate calling code within the template or
> function.
>
> As an example for such a pattern see the invoke() method of Java's
> java.lang.reflect.Method class [1], specifically the exception type
> InvocationTargetException.

To me, wrapping the exception is a work around; a kind of information
    clouding which requires extra work at both ends. (I note that it
    is less work in Java, however.)

>
> [1]
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Method.html

You mean this part?

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Method.html#invoke(java.lang.Object,%20java.lang.Object[])
http://xrl.us/cr57

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> I had a very hard time understanding C++'s exception mechanism.  I'm still
> not certain I understand it all.  I believe it would have made far more
> sense if C++ required, by default, all exceptions be derived from
> std::exception.  That seems like a reasonable approach to every situation I
> have used exceptions for.  There may be a reason to uses lighter weight
> objects such as int, or even bool in some IO code.  Such atypical
> situations could be handles by something similar to std::set_unexpected().

Single-rooted inheritance hierarchies are against the spirit of C++.
I can't see any reason to impose the requirement you propose.

The *only* reason I can see to require derivation from std::exception
is because some OS vendors made the mistake of winding other things
that should never have been C++ exceptions into the C++ exception
mechanism, causing catch(...) to interact badly with some conditions
(like asserts and segfaults).  If we build the requirement you propose
into the language, won't OS vendors make these "OS exceptions" derived
from std::exception, too?

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<OsudnXjJtfIgv4HcRVn-pA@speakeasy.net>...
> Bob Bell wrote:
>
> >> Would exception<ObjectType> expand to a complete list of all the
> >> exceptions that might be thrown by any function that has ObjectType in
> >> its signature? That would be broad enough to do this job, but too
> >> broad to be useful.
> >
> > Not to mention, what would you catch? The whole point was to tell a
> > caller what exceptions to expect to be thrown, so you know what to
> > catch. If the interface to a function contains
> > "throw(exception<ObjectType>)", where it's understood that
> > "exception<ObjectType>" somehow expands to anything that ObjectType
> > can throw, then I can't tell by looking at the interface what to
> > catch. So it doesn't even do what was originally desired.
> >
> > Bob
> >
>
> We could look at ObjectType to find the exceptions that should be extracted.
> I believe the only times the object will throw are when it is instantiated,
> or when a member function is invoked.

class Foo { };
class Bar { };

void G(const Foo&) throw(X, Y)
{
// ...
}

void G(const Bar&) throw (Z)
{
// ...
}

template<typename T>
void F(T& obj)
{
   G(obj);
}

int main()
{
   Foo  f;
   Bar  b;

   F(f);
   F(b);
}

This isn't a particularly complex example; how would you account for
it? The exceptions that F() can throw is not dependent on the
exceptions that Foo and Bar can throw.

> Having the exception specification
> is not just a convenience for the programmer, it is a means for the
> compiler to check what might be thrown.

This is a lot more difficult (and a lot less useful, IMHO) than it
might seem at first.

> An alternative approach would be to
> have specific exceptions defined for the template.  These would have a
> member field which could hold a cause exception.

How would this make the example above work?

template<typename T>
void F(T& obj) throw(XXX)
{
   G(obj);
}

How would you define XXX? Note that when T is Foo, G can throw an X or
a Y.

> That way, the
> instantiated template could catch whatevery is thrown to it, wrap it up in
> some exception it specifically advertises in its interface, and throw that.
> This kind of strategy is used in Apache's Java application servers.  I've
> found it very useful, and easy to understand.

Sure. But Java forces all exceptions to derive from a particular class
(C++ doesn't), and Java doesn't have templates. It seems clear to me
that reasoning about C++'s exception handling based on what Java can
do is of limited utility.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<OsudnXjJtfIgv4HcRVn-pA@speakeasy.net>...
Steven T. Hatton wrote:
..
> We could look at ObjectType to find the exceptions that should be extracted. I
> believe the only times the object will throw are when it is instantiated,
> or when a member function is invoked.  Having the exception specification


What about exceptions thrown by non-member functions, particularly
operator overloads, that involve that type?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:
[snip]

> The following suggests there may be no fundamental reason C++ could not have
> a more coherent exception mechanism.
>
> http://es-sun2.fernuni-hagen.de/cgi-bin/info2html?(gcc)Java%20Exceptions

This link is only about run-time compatiblity of Java and C++
    exceptions within a particular implementation. It has nothing
    whatsoever to do with adding the compile time semantics of java
    exceptions to C++; nothing to do with requiring all functions
    that might throw declare all of their exceptions in thier throw
    clause.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

qrczak@knm.org.pl ("Marcin 'Qrczak' Kowalczyk") writes:

> On Mon, 09 Aug 2004 16:42:45 +0000, Steven T. Hatton wrote:
>
>> 2) I don't know what, if any exceptions a funciton is likely to throw, if
>> there is no (throw) in the function signature. (I'm not sure if that is
>> technically part of the signature - but it aughta be!) So I propose that,
>> by default, all function that might throw an exception should be requiered
>> to state that they throw an exception, and what kind.
>
> What would be the signature of this function template?
>
>     template<class InputIterator, class OutputIterator, class UnaryOperation>
>       OutputIterator transform(InputIterator first, InputIterator last,
>                                OutputIterator result, UnaryOperation op);

The 'obvious' compromise would be that the signature of a function
    template include only those exceptions which may be thrown by
    non-depenendent operations. Exceptions thrown by dependent
    operations would be the responsibility of functions
    containing specific instantiations of transform. In this case, I
    think 'transform' can be implemented entirely without
    non-depenendent operations, so its signature should contain
    'throw()' - meaning it throws only those exceptions thrown by the
    dependent operations it performs.

I say 'obvious' because it seems natural to me that dependent names
    are the responsibility of the code which instantiates a template,
    while non-dependent names are the responsibility of the code
    which defines it.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net (James Kuyper) writes:

> hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<d72dnZLTyL09pITcRVn-uQ@speakeasy.net>...
>> Marcin 'Qrczak' Kowalczyk wrote:
>>
>>
>>> On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:
>>>
>>>
>>>>>    template<class InputIterator, class OutputIterator, class
>>>>>    UnaryOperation>
>>>>>      OutputIterator transform(InputIterator first, InputIterator
> last,
>>>>>                               OutputIterator result,
> UnaryOperation
>>>>>                               op);
>>>>
>>>>
>>>> Without resorting to a formal definition, I would say that it
> doesn't
>>>> have a
>>>> signature, per se.  I would say it has a potential signature, or,
>>>> perhaps,
>>>> a meta-signature.  A function produced by instantiating it would
> have a
>>>> signature determined by the template arguments used to instantiate
> it.
>>>> So, in the case of templates, I guess the rule should apply to the
> types
>>>> produced from it.
>>>
>>>
>>> It doesn't matter for now whether it's called signature or
> something else.
>>> I meant: what would be written in the header file instead of this
> if
>>> exception specifications were mandatory as you propose?
> ..
>> Or even better. Figure out a way of extracting exception information from
>> the arguments passed to the template, and stick them in the resulting
>> function signatures.  There could be something like throws( exception<T>,
>> exception<TT>) where exception<T> might expand into multiple exception
>> types, if T throws multiple types.  But you can only do that it the
>> exceptions are in the signatures. (or in some other way advertised to the
>> compiler instantiating the template.)
>
> That works when T is a function type, where it's meaningful to say
> that 'T throws an exception'. However, what about the case above, with
> transform<>? The template arguments are object types, not functions.
> What is actually wanted is a complete list of the exception types
> thrown by any function that might be invoked during the instantiation
> of template for a particular set of template arguments. That can
> involve a wide variety of overloaded functions, including, for
> example, non-member operator overloads. It's not easy, or even
> possible, to write out the complete list of such functions for a
> generic template; it could only be done for specific instantiations.
>
> Would exception<ObjectType> expand to a complete list of all the
> exceptions that might be thrown by any function that has ObjectType in
> its signature? That would be broad enough to do this job, but too
> broad to be useful.

I think all this discussion about how the definition or declaration
    of a template can (or can't :-) describe the exceptions which may
    be thrown by the depenendent operations is misplaced.

Why? Ask yourself whose responsibility those exceptions are. If I
    instantiate the aformentioned transform template, whose
    responsibility are the semantics of, say, 'UnaryOperation' ?
    Mine, mine alone. It isn't up to the definition of 'transform' to
    describe the semantics of 'UnaryOperation'. That's my
    job. Exceptions thrown by the operations of 'UnaryOperation' are
    part of those semantics - and therefor my responsibility. The
    definition of transform has no business saying anything about the
    exceptions which may or may not be thrown by depenendent
    operations - that's the responsibility of those who instantiate
    the template.

So in a better C++, adding 'throw()' to a function template's
    declaration or definition would mean only that the non-dependent
    operations used by the function template did not throw. Whether
    or not the depenendent operations threw would be the users
    problem. However C++ would need new syntax to do it now; the
    existing syntax already has the current horribly broken
    semantics.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

usenet-nospam@nmhq.net (Niklas Matthies) writes:

> On 2004-08-10 15:34, "Marcin 'Qrczak' Kowalczyk" wrote:
>> On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:
>>
>>>>     template<class InputIterator, class OutputIterator, class
>>>>     UnaryOperation>
>>>>       OutputIterator transform(InputIterator first, InputIterator last,
>>>>                                OutputIterator result, UnaryOperation op);
>>>
>>> Without resorting to a formal definition, I would say that it
>>> doesn't have a signature, per se.  I would say it has a potential
>>> signature, or, perhaps, a meta-signature.  A function produced by
>>> instantiating it would have a signature determined by the template
>>> arguments used to instantiate it. So, in the case of templates, I
>>> guess the rule should apply to the types produced from it.
>>
>> It doesn't matter for now whether it's called signature or something
>> else. I meant: what would be written in the header file instead of
>> this if exception specifications were mandatory as you propose?
>
> Given a way to generate, from an expression, a typelist of the types
> listed in the exception specifications of any function call
> sub-expression of the expression (think along the lines of typeof),
> and a way to make an exception specification from a typelist, one
> could write a template argument dependend exception specification for
> template functions.
>
> The question is rather whether being able to do so is really
> desirable.

In my opinion, exceptions thrown by dependent operations are not the
    responsibility of the template's definition, and therefor, the
    implementor should have no such desire.

The instantiator of a template, on the other hand, may have some
    reason, since he bears responsibility for exceptions thrown by
    dependent operations.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
> [snip]
>
>> The following suggests there may be no fundamental reason C++ could not
>> have a more coherent exception mechanism.
>>
>> http://es-sun2.fernuni-hagen.de/cgi-bin/info2html?(gcc)Java%20Exceptions
>
> This link is only about run-time compatiblity of Java and C++
>     exceptions within a particular implementation. It has nothing
>     whatsoever to do with adding the compile time semantics of java
>     exceptions to C++; nothing to do with requiring all functions
>     that might throw declare all of their exceptions in thier throw
>     clause.
>

I was only presenting it as an example of C++
extended/hacked/mangled/whatever_you_want_to_call_it to use a different
kind of exception mechanism than that specified in the Standard.  I have
not tried using it, but, as I read the document, you can actually /use/
Java-style exceptions in code that is otherwise C++.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <86d61ru2qh.fsf@Zorthluthik.local.bar>, llewelly
<llewelly.at@xmission.dot.com> writes
>So in a better C++, adding 'throw()' to a function template's
>    declaration or definition would mean only that the non-dependent
>    operations used by the function template did not throw. Whether
>    or not the depenendent operations threw would be the users
>    problem. However C++ would need new syntax to do it now; the
>    existing syntax already has the current horribly broken
>    semantics.

That way lies madness without any benefits.

I think our experience of exceptions and exception specifications in C++
(and in Java) demonstrate that the only possible benefit is the ability
to specify that a function never throws (that, for example, makes it
safely callable from C code)

I think this is just one example of allowing programmers to make
guarantees about their code can enhance the potential for optimisation.
We already have const values (not const references) that allow the
compiler to use a named value without the costs of creating and
accessing an object. We have mutable that allows the compiler to make
assumptions if it is not present in a class definition. We could have
some way to tell a compiler that a function is free of side effects (and
I think that could even be verifiable in the same way that const is) but
note that const member functions are not examples of such functions.

Note that evaluations of pure (without side-effect) functions are
inherently re-orderable which is significant in the context of another
thread (one concerned with order of evaluation). Given f() and g() are
pure functions either can be evaluated first (or both in parallel) to
get the value of f() op g(). For non-pure functions different orderings
may (and often do) result in different visible behaviour.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

francis@robinton.demon.co.uk (Francis Glassborow) writes:

> In article <86d61ru2qh.fsf@Zorthluthik.local.bar>, llewelly
> <llewelly.at@xmission.dot.com> writes
>>So in a better C++, adding 'throw()' to a function template's
>>    declaration or definition would mean only that the non-dependent
>>    operations used by the function template did not throw. Whether
>>    or not the depenendent operations threw would be the users
>>    problem. However C++ would need new syntax to do it now; the
>>    existing syntax already has the current horribly broken
>>    semantics.
>
> That way lies madness without any benefits.

The Throws specification for std::list<>::remove_if() is:

    23.2.24/16:
    # Throws: Nothing unless an exception is thrown by *i == value or
      pred(*i) != false.

For list<>::unique() we find something similar:

    23.2.24/20:
    # Throws: Nothing unless an exception in thrown by *i == *(i-1) or
      pred(*i, *(i - 1))

I don't think this is madness; pred and operator== are provided by the
    user(s) of remove_if and unique, and therefor it is quite natural
    that the specifications of these two functions say nothing about
    whether exceptions are thrown by pred or operator==.

The benefit is that remove_if and unique can be specified to throw no
    exceptions if the user provides operations which throw no
    exceptions, while at the same time allowing a user to provide a
    pred or operator== which throws.

Many standard library functions have similar throws clauses. What I
    suggest above is analogus to these clauses, but (rather than mere
    documentation) a feature checked at compile time.

So I would appreciate if you would explain why you think my
    suggestion is 'madness'.

>
> I think our experience of exceptions and exception specifications in
> C++ (and in Java) demonstrate that the only possible benefit is the
> ability to specify that a function never throws (that, for example,
> makes it safely callable from C code)

But for a template, such a specification is sometimes too strict; it
    restricts the kinds of operations the user may provide, when it
    may be that no such restriction is necessary.

> I think this is just one example of allowing programmers to make
> guarantees about their code can enhance the potential for
> optimisation.

Note that my goal is not (in this case) optimisation. It is making
    exception-safe code a little easier to write.

> We already have const values (not const references) that
> allow the compiler to use a named value without the costs of creating
> and accessing an object. We have mutable that allows the compiler to
> make assumptions if it is not present in a class definition. We could
> have some way to tell a compiler that a function is free of side
> effects (and I think that could even be verifiable in the same way
> that const is) but note that const member functions are not examples
> of such functions.
[snip]

It would seem to me that a pure member funcion would also be const,
    but a const member funcion would not necessarily be pure.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> llewelly wrote:
>
>> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
>> [snip]
>>
>>> The following suggests there may be no fundamental reason C++ could not
>>> have a more coherent exception mechanism.
>>>
>>> http://es-sun2.fernuni-hagen.de/cgi-bin/info2html?(gcc)Java%20Exceptions
>>
>> This link is only about run-time compatiblity of Java and C++
>>     exceptions within a particular implementation. It has nothing
>>     whatsoever to do with adding the compile time semantics of java
>>     exceptions to C++; nothing to do with requiring all functions
>>     that might throw declare all of their exceptions in thier throw
>>     clause.
>>
>
> I was only presenting it as an example of C++
> extended/hacked/mangled/whatever_you_want_to_call_it to use a different
> kind of exception mechanism than that specified in the Standard.  I have
> not tried using it, but, as I read the document, you can actually /use/
> Java-style exceptions in code that is otherwise C++.

You are in some sense mistaken; the only thing which makes them
    java-style is that java code built with the GCC java front-end
    can safely catch them. No compile-time checking is provided.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2004-08-16 16:34, llewelly wrote:
> usenet-nospam@nmhq.net (Niklas Matthies) writes:
:
> In my opinion, exceptions thrown by dependent operations are not the
>     responsibility of the template's definition, and therefor, the
>     implementor should have no such desire.

The fact that the caller might not be able to detect whether an
exception comes from a dependent operation or from a non-dependent
operation (because both may throw exceptions of the same type) could
be a reason to wrap exceptions thrown by dependent operations into
a dedicated type.

More generally put, I don't see a great difference between templates
invoking dependent operations and functions performing callbacks on
function pointers or functor objects, or even just virtual member
functions. In either case the exceptions thrown by the inner operation
may be unknown to the immediate calling code within the template or
function.

As an example for such a pattern see the invoke() method of Java's
java.lang.reflect.Method class [1], specifically the exception type
InvocationTargetException.

[1] http://java.sun.com/j2se/1.4.2/docs/api/java/lang/reflect/Method.html

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcin 'Qrczak' Kowalczyk wrote:

> On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:
>=20
>>>     template<class InputIterator, class OutputIterator, class
>>>     UnaryOperation>
>>>       OutputIterator transform(InputIterator first, InputIterator las=
t,
>>>                                OutputIterator result, UnaryOperation
>>>                                op);
>>=20
>> Without resorting to a formal definition, I would say that it doesn't
>> have a
>> signature, per se.  I would say it has a potential signature, or,
>> perhaps,
>> a meta-signature.  A function produced by instantiating it would have =
a
>> signature determined by the template arguments used to instantiate it.
>> So, in the case of templates, I guess the rule should apply to the typ=
es
>> produced from it.
>=20
> It doesn't matter for now whether it's called signature or something el=
se.
> I meant: what would be written in the header file instead of this if
> exception specifications were mandatory as you propose?
>=20

It may be a bit unseemly, but I just responded to a similar question on
comp.lang.c++, so I'm going to use that as my response.  I replied to my
own message, so the first level of quotation was written my me, as well a=
s
the unquoted text:
=20
Steven T. Hatton wrote:

> tom_usenet wrote:
>=20
>> On Mon, 09 Aug 2004 15:34:24 -0400, "Steven T. Hatton"
>> <susudata@setidava.kushan.aa> wrote:
>>=20
>>>I disagree that the use of the above mechanism is as convenient as
>>>catch(exception& e) {
>>> std::cerr << e.what();
>>>}
>>=20
>> No, but you maintain backwards compatibility, in that exceptions don't
>> have to derive from std::exception.
>=20
> Backward compatability should be handled by allowing for the use of a
> deprecated feature at some level of inconvenience to the user.=A0=A0I'm=
=A0not
> sure how it might be accomplished without the use of the preprocessor, =
but
> I'm confident that a mechanism similar to set_unexpected could be
> specified as a means of changing the exception handling policies.
>=20
>>>> What about templates?
>>>
>>>What about templates? Looking over the STL, there don't seem to be any
>>>exception specification other than throw().=A0=A0I=A0haven't=A0read=A0=
all=A046=A0pages
>>>of the Standard =A714, but, AFAIK, it doesn't preclude the use of exce=
ption
>>>specifications.=A0=A0There=A0seems=A0to=A0be=A0an=A0issue=A0here,=A0bu=
t=A0I'm=A0not=A0sure=A0what
>>>it is.
>>=20
>> The exceptions that a template function throws depends on the types of
>> the template parameters. e.g. std::sort throws if the comparator
>> throws, or if moving the elements around throws, etc., but what or
>> whether these throw depends entirely upon the types that std::sort is
>> instantiated with, so you can't give std::sort an exception
>> specification (beyond an overly permissive throw (std::exception)).
>=20
> That doesn't seem to add up.=A0=A0We=A0could=A0still=A0have=A0a=A0std::=
sort_exception
> with
> a cause exception wrapped up in it.=A0=A0All=A0you=A0need=A0to=A0do=A0i=
s=A0something=A0like
> `throw new exception("message string", ex)', where ex is the old
> exception. Since exceptions are intended to be exceptional, there shoul=
d
> be no significant hit on performace resulting from the optional extra
> cargo in
> the throw.=A0=A0If=A0some=A0support=A0for=A0introspection=A0were=A0intr=
oduced=A0into=A0the
> language, it would even be possible to make exceptions self-aware, and
> capable of telling you what they are, without their exact type being in
> scope.
>=20
> Yes, this idea is directly from Java, and it's a damn good idea.=A0=A0T=
here
> may be legitimate arguments against adding it to C++, but I can perceiv=
e
> any.

Or even better. Figure out a way of extracting exception information from
the arguments passed to the template, and stick them in the resulting
function signatures.=A0=A0There=A0could=A0be=A0something=A0like=A0throws(=
=A0exception<T>,
exception<TT>) where exception<T> might expand into multiple exception
types, if T throws multiple types.=A0=A0But=A0you=A0can=A0only=A0do=A0tha=
t=A0it=A0the
exceptions are in the signatures. (or in some other way advertised to the
compiler instantiating the template.)
--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2004-08-10 15:34, "Marcin 'Qrczak' Kowalczyk" wrote:
> On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:
>
>>>     template<class InputIterator, class OutputIterator, class
>>>     UnaryOperation>
>>>       OutputIterator transform(InputIterator first, InputIterator last,
>>>                                OutputIterator result, UnaryOperation op);
>>
>> Without resorting to a formal definition, I would say that it
>> doesn't have a signature, per se.  I would say it has a potential
>> signature, or, perhaps, a meta-signature.  A function produced by
>> instantiating it would have a signature determined by the template
>> arguments used to instantiate it. So, in the case of templates, I
>> guess the rule should apply to the types produced from it.
>
> It doesn't matter for now whether it's called signature or something
> else. I meant: what would be written in the header file instead of
> this if exception specifications were mandatory as you propose?

Given a way to generate, from an expression, a typelist of the types
listed in the exception specifications of any function call
sub-expression of the expression (think along the lines of typeof),
and a way to make an exception specification from a typelist, one
could write a template argument dependend exception specification for
template functions.

The question is rather whether being able to do so is really
desirable.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<d72dnZLTyL09pITcRVn-uQ@speakeasy.net>...
> Marcin 'Qrczak' Kowalczyk wrote:
>
>
>> On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:
>>
>>
>>>>    template<class InputIterator, class OutputIterator, class
>>>>    UnaryOperation>
>>>>      OutputIterator transform(InputIterator first, InputIterator
last,
>>>>                               OutputIterator result,
UnaryOperation
>>>>                               op);
>>>
>>>
>>> Without resorting to a formal definition, I would say that it
doesn't
>>> have a
>>> signature, per se.  I would say it has a potential signature, or,
>>> perhaps,
>>> a meta-signature.  A function produced by instantiating it would
have a
>>> signature determined by the template arguments used to instantiate
it.
>>> So, in the case of templates, I guess the rule should apply to the
types
>>> produced from it.
>>
>>
>> It doesn't matter for now whether it's called signature or
something else.
>> I meant: what would be written in the header file instead of this
if
>> exception specifications were mandatory as you propose?
..
> Or even better. Figure out a way of extracting exception information from
> the arguments passed to the template, and stick them in the resulting
> function signatures.  There could be something like throws( exception<T>,
> exception<TT>) where exception<T> might expand into multiple exception
> types, if T throws multiple types.  But you can only do that it the
> exceptions are in the signatures. (or in some other way advertised to the
> compiler instantiating the template.)

That works when T is a function type, where it's meaningful to say
that 'T throws an exception'. However, what about the case above, with
transform<>? The template arguments are object types, not functions.
What is actually wanted is a complete list of the exception types
thrown by any function that might be invoked during the instantiation
of template for a particular set of template arguments. That can
involve a wide variety of overloaded functions, including, for
example, non-member operator overloads. It's not easy, or even
possible, to write out the complete list of such functions for a
generic template; it could only be done for specific instantiations.

Would exception<ObjectType> expand to a complete list of all the
exceptions that might be thrown by any function that has ObjectType in
its signature? That would be broad enough to do this job, but too
broad to be useful.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kuyper wrote:

> Would exception<ObjectType> expand to a complete list of all the
> exceptions that might be thrown by any function that has ObjectType in
> its signature? That would be broad enough to do this job, but too
> broad to be useful.

You may want to read the last paragraph first.

Yet another reason to want all functions to be members of some class.  But I
don't believe this is a show-stopper. If we start from the most inclusive
exception specification `throws(std::exception)' and work toward a more
refined specification generated during templated instantiation, we can
probably determine where it is reasonable to expect the compiler to extract
useful, more refined, exception specifications.

If we take the absence of an exception specification to mean 'there may be
an exception thrown, but at the time of binding the exact types could not
be determined', we could understand it to be an implied `throw
(std::exception)' (or perhaps even `throw (std::unspecified_exception)'.)
There could be 'reasonable' circumstances when the compiler slaps you on
the wrist for not being specific about what might be thrown. For example,
if a function template called a Standard Library function know to throw an
exception (perhaps specified by an exception template), that exception
(template) should appear in the exception list of the template function.
Other times it might handle unspecified exceptions as `I couldn't figure it
out, why should I expect a mere programmer to figure it our?' In such cases
it would accept the absence of an exception specification, or the absence
of a specific type of exception.

I have to confess I am not, by any means, an expert on the use of templates.
That may be an advantage at this point.  My ideas are not constrained by
mere matters of fact.  I am able to speculate about things a more
knowlegible person wouldn't even consider.  At this point my approach is
this: Template programming is meta-programming.  We are writing code that
writes code.  A template is a programmatic abstraction representing
commonality shared by all entities produced by its instantiation.  There
are inputs, and outputs.  The inputs can provide explicit information about
exceptions which could be extracted and used in the exception specification
of the instantiated template.  The templates themselves might contain the
functions which generate exceptions.  For example a sort function template
might throw a specific exception (perhaps based on an exception template
parameterize by the arguments to the sort).

In the case of instantiation of classed created from templates, there might
be a specific instantiation exception base class from which all exceptions
thrown during instantiation are derived.  If the exception is generated by
a call to a function that could not have been forseen at the time the
template was created, that exception could be wrapped up in the
instantiation exception as a member variable.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0408111754.5417bbea@posting.google.com>...
> hattons@globalsymmetry.com ("Steven T. Hatton") wrote in message news:<d72dnZLTyL09pITcRVn-uQ@speakeasy.net>...
> > Marcin 'Qrczak' Kowalczyk wrote:
> >
> >
> >> On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:
> >>
> >>
> >>>>    template<class InputIterator, class OutputIterator, class
> >>>>    UnaryOperation>
> >>>>      OutputIterator transform(InputIterator first, InputIterator
>  last,
> >>>>                               OutputIterator result,
>  UnaryOperation
> >>>>                               op);
> >>>
> >>>
> >>> Without resorting to a formal definition, I would say that it
>  doesn't
> >>> have a
> >>> signature, per se.  I would say it has a potential signature, or,
> >>> perhaps,
> >>> a meta-signature.  A function produced by instantiating it would
>  have a
> >>> signature determined by the template arguments used to instantiate
>  it.
> >>> So, in the case of templates, I guess the rule should apply to the
>  types
> >>> produced from it.
> >>
> >>
> >> It doesn't matter for now whether it's called signature or
>  something else.
> >> I meant: what would be written in the header file instead of this
>  if
> >> exception specifications were mandatory as you propose?
>  ..
> > Or even better. Figure out a way of extracting exception information from
> > the arguments passed to the template, and stick them in the resulting
> > function signatures.  There could be something like throws( exception<T>,
> > exception<TT>) where exception<T> might expand into multiple exception
> > types, if T throws multiple types.  But you can only do that it the
> > exceptions are in the signatures. (or in some other way advertised to the
> > compiler instantiating the template.)
>
> That works when T is a function type, where it's meaningful to say
> that 'T throws an exception'. However, what about the case above, with
> transform<>? The template arguments are object types, not functions.
> What is actually wanted is a complete list of the exception types
> thrown by any function that might be invoked during the instantiation
> of template for a particular set of template arguments. That can
> involve a wide variety of overloaded functions, including, for
> example, non-member operator overloads. It's not easy, or even
> possible, to write out the complete list of such functions for a
> generic template; it could only be done for specific instantiations.
>
> Would exception<ObjectType> expand to a complete list of all the
> exceptions that might be thrown by any function that has ObjectType in
> its signature? That would be broad enough to do this job, but too
> broad to be useful.

Not to mention, what would you catch? The whole point was to tell a
caller what exceptions to expect to be thrown, so you know what to
catch. If the interface to a function contains
"throw(exception<ObjectType>)", where it's understood that
"exception<ObjectType>" somehow expands to anything that ObjectType
can throw, then I can't tell by looking at the interface what to
catch. So it doesn't even do what was originally desired.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:

>> Would exception<ObjectType> expand to a complete list of all the
>> exceptions that might be thrown by any function that has ObjectType in
>> its signature? That would be broad enough to do this job, but too
>> broad to be useful.
>
> Not to mention, what would you catch? The whole point was to tell a
> caller what exceptions to expect to be thrown, so you know what to
> catch. If the interface to a function contains
> "throw(exception<ObjectType>)", where it's understood that
> "exception<ObjectType>" somehow expands to anything that ObjectType
> can throw, then I can't tell by looking at the interface what to
> catch. So it doesn't even do what was originally desired.
>
> Bob
>

We could look at ObjectType to find the exceptions that should be extracted.
I believe the only times the object will throw are when it is instantiated,
or when a member function is invoked.  Having the exception specification
is not just a convenience for the programmer, it is a means for the
compiler to check what might be thrown. An alternative approach would be to
have specific exceptions defined for the template.  These would have a
member field which could hold a cause exception.  That way, the
instantiated template could catch whatevery is thrown to it, wrap it up in
some exception it specifically advertises in its interface, and throw that.
This kind of strategy is used in Apache's Java application servers.  I've
found it very useful, and easy to understand.

It's conceivable that there could be a way to extract interface information
from an instantiated template as part of the development process.  I've
been thinking about this over the past few days.  Templates don't look like
classes to me.  An instantiated template should be representable as a class
definition.  I'm not suggesting the Standard should try to specify a means
for doing so.  I don't know if it would be a reasonable assumption that
implementations would provide such a feature.


--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I had a very hard time understanding C++'s exception mechanism.  I'm still
not certain I understand it all.  I believe it would have made far more
sense if C++ required, by default, all exceptions be derived from
std::exception.  That seems like a reasonable approach to every situation I
have used exceptions for.  There may be a reason to uses lighter weight
objects such as int, or even bool in some IO code.  Such atypical
situations could be handles by something similar to std::set_unexpected().

I would even like to see something along the lines of

catch(std::unknown_exception e)

in as a substitue for catch(...)

std::unknown_exception would be constructed on the basis of what can be
gleened from the exception, if anything.  It would derive from
std::exception, and could subsequently be treated just as if a
std::exception had been thrown.

If there is a reason to rethrow the raw exception catch(...) could still be
used.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

    You're right, but it's too late to fix it.

    There's a lot of stuff like that in C++.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

> I had a very hard time understanding C++'s exception mechanism.  I'm st=
ill
> not certain I understand it all.  I believe it would have made far more
> sense if C++ required, by default, all exceptions be derived from
> std::exception.  That seems like a reasonable approach to every situati=
on
> I
> have used exceptions for.  There may be a reason to uses lighter weight
> objects such as int, or even bool in some IO code.  Such atypical
> situations could be handles by something similar to std::set_unexpected=
().
>=20
> I would even like to see something along the lines of
>=20
> catch(std::unknown_exception e)
>=20
> in as a substitue for catch(...)
>=20
> std::unknown_exception would be constructed on the basis of what can be
> gleened from the exception, if anything.  It would derive from
> std::exception, and could subsequently be treated just as if a
> std::exception had been thrown.
>=20
> If there is a reason to rethrow the raw exception catch(...) could stil=
l
> be used.

I posted this to comp.lang.c++ and decided it might be worth posting here=
 as
well.

The two biggest objections I have to the current form of C++ exception
handling are:

1) I don't know what I'm likely to catch. So I propose requiering that, b=
y
default, all exceptions should be derived from std::exception (or a
suitable, similar class.)


2) I don't know what, if any exceptions a funciton is likely to throw, if
there is no (throw) in the function signature. (I'm not sure if that is
technically part of the signature - but it aughta be!) So I propose that,
by default, all function that might throw an exception should be requiere=
d
to state that they throw an exception, and what kind.=A0=A0Either=A0by=A0=
explicitly
enumerating the possible types, or by nameing (a) baseclass(es) of all
exceptions thrown.=A0=A0If=A0a=A0function=A0does=A0not=A0catch=A0and=A0ha=
ndle=A0an=A0exception
thrown by a call it invokes, it must decare that it might throw that kind
of exception, or a suitable base class.


The following suggests there may be no fundamental reason C++ could not h=
ave
a more coherent exception mechanism.

http://es-sun2.fernuni-hagen.de/cgi-bin/info2html?(gcc)Java%20Exceptions

--=20
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 09 Aug 2004 16:42:45 +0000, Steven T. Hatton wrote:

> 2) I don't know what, if any exceptions a funciton is likely to throw, if
> there is no (throw) in the function signature. (I'm not sure if that is
> technically part of the signature - but it aughta be!) So I propose that,
> by default, all function that might throw an exception should be requiered
> to state that they throw an exception, and what kind.

What would be the signature of this function template?

    template<class InputIterator, class OutputIterator, class UnaryOperation>
      OutputIterator transform(InputIterator first, InputIterator last,
                               OutputIterator result, UnaryOperation op);

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marcin 'Qrczak' Kowalczyk wrote:

> On Mon, 09 Aug 2004 16:42:45 +0000, Steven T. Hatton wrote:
>
>> 2) I don't know what, if any exceptions a funciton is likely to throw, if
>> there is no (throw) in the function signature. (I'm not sure if that is
>> technically part of the signature - but it aughta be!) So I propose that,
>> by default, all function that might throw an exception should be
>> requiered to state that they throw an exception, and what kind.
>
> What would be the signature of this function template?
>
>     template<class InputIterator, class OutputIterator, class
>     UnaryOperation>
>       OutputIterator transform(InputIterator first, InputIterator last,
>                                OutputIterator result, UnaryOperation op);
>

Without resorting to a formal definition, I would say that it doesn't have a
signature, per se.  I would say it has a potential signature, or, perhaps,
a meta-signature.  A function produced by instantiating it would have a
signature determined by the template arguments used to instantiate it. So,
in the case of templates, I guess the rule should apply to the types
produced from it.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 10 Aug 2004 06:14:43 +0000, Steven T. Hatton wrote:

>>     template<class InputIterator, class OutputIterator, class
>>     UnaryOperation>
>>       OutputIterator transform(InputIterator first, InputIterator last,
>>                                OutputIterator result, UnaryOperation op);
>
> Without resorting to a formal definition, I would say that it doesn't have a
> signature, per se.  I would say it has a potential signature, or, perhaps,
> a meta-signature.  A function produced by instantiating it would have a
> signature determined by the template arguments used to instantiate it. So,
> in the case of templates, I guess the rule should apply to the types
> produced from it.

It doesn't matter for now whether it's called signature or something else.
I meant: what would be written in the header file instead of this if
exception specifications were mandatory as you propose?

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]