Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Catching exceptions

Reply
Thread Tools

Catching exceptions

 
 
magnus.moraberg@gmail.com
Guest
Posts: n/a
 
      05-11-2009
Hi,

I have the following incomplete code -

File file;
file.open(filePath);

try
{
someOneElsesApi::startComplexProcessingOfFile(file );
std::cout << "The file is now processed" << std::endl;
}
catch exception(/* all exceptions */)
{
std::cout << "The file didn't process because: " << std::endl;
}

startComplexProcessingOfFile() can throw a whole range of different
exceptions.

How do I catch them and inform the user in a useful manner. In python,
there is a base exception class which can be used for this purpose. C#
has inner exceptions which I also found quite useful.

Thanks for your help,
 
Reply With Quote
 
 
 
 
Vladimir Jovic
Guest
Posts: n/a
 
      05-11-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi,
>
> I have the following incomplete code -
>
> File file;
> file.open(filePath);
>
> try
> {
> someOneElsesApi::startComplexProcessingOfFile(file );
> std::cout << "The file is now processed" << std::endl;
> }
> catch exception(/* all exceptions */)
> {
> std::cout << "The file didn't process because: " << std::endl;
> }
>
> startComplexProcessingOfFile() can throw a whole range of different
> exceptions.
>
> How do I catch them and inform the user in a useful manner. In python,
> there is a base exception class which can be used for this purpose. C#
> has inner exceptions which I also found quite useful.


You can use:
catch(...)
but it will catch all exceptions, and you will not know which one is caught.

It is better to create all catch cases, and act accordingly. After all,
you should know which exceptions are thrown, and what can be done for each.

Something like:

try
{
f(); // throws an exception
}
catch ( const exception1 &e )
{
// do 1
}
catch ( const exception2 &e )
{
// do 2
}
catch ( ... )
{
// ?
}
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-11-2009
* (E-Mail Removed):
>
> I have the following incomplete code -
>
> File file;
> file.open(filePath);
>
> try
> {
> someOneElsesApi::startComplexProcessingOfFile(file );
> std::cout << "The file is now processed" << std::endl;
> }
> catch exception(/* all exceptions */)
> {
> std::cout << "The file didn't process because: " << std::endl;
> }
>
> startComplexProcessingOfFile() can throw a whole range of different
> exceptions.
>
> How do I catch them and inform the user in a useful manner. In python,
> there is a base exception class which can be used for this purpose. C#
> has inner exceptions which I also found quite useful.


If the exceptions are all derived from some base class T (e.g. std::exception),
just do

try
{
// Whatever.
}
catch( std::exception const& x )
{
std::cerr << "!" << x.what() << std::endl;
}

If the exceptions are of unrelated types then you can do

try
{
// Whatever.
}
catch( ... )
{
std::cerr << "!" << exceptionText() << std::endl;
}

where exceptionText is a routine that you have defined tailored to the exception
types you expect, e.g. like

std::string exceptionText()
{
try
{
throw;
}
catch( A const& a )
{
return exceptionTextFrom( a );
}
catch( B const& b )
{
return exceptionTextFrom( b )
}
catch( C const& c )
{
return exceptionTextFrom( c );
}
catch( std::exception const& x )
{
return x.what();
}
catch( ... )
{
return "Uknown exception";
}
}

where exceptionTextFrom might be a routine that you define, or just direct code
to access the exception object's message.

For anything but the smallest program it is however generally a bad idea to
present the message carried by an exception to the user as a main message. It's
probably not adapted to the context it appears in. It's probably about internal
technical details that the user doesn't care about and doesn't have access to.
It's probably expressed in a technical terminology/jargon that the user doesn't
understand. It may even be in a national language that user doesn't understand.
Exception information is generally for programmers (e.g. log it).

Cheers & hth,

- Alf

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! Just going there is good. Linking
to it is even better! Thanks in advance!
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      05-11-2009
On Mon, 11 May 2009 01:52:15 -0700 (PDT), (E-Mail Removed) <(E-Mail Removed)> wrote:
> Hi,
>
> I have the following incomplete code -
>
> File file;
> file.open(filePath);
>
> try
> {
> someOneElsesApi::startComplexProcessingOfFile(file );
> std::cout << "The file is now processed" << std::endl;


Do you use std::endl here because you explicitly want flushing of cout
at this point, or because you mistakenly think \n is not portable?

> }
> catch exception(/* all exceptions */)
> {
> std::cout << "The file didn't process because: " << std::endl;
> }
>
> startComplexProcessingOfFile() can throw a whole range of different
> exceptions.
>
> How do I catch them and inform the user in a useful manner. In python,
> there is a base exception class which can be used for this purpose.


Not really. As far as I know, Python is like C++; you can throw any
object. And even if there *was* such an Exception class, you would
want to catch IOError in this case, to be able to tell the user
something meaningful like "failed because 'foo.txt' is read
protected".

Returning to C++ ... if someOneElsesApi::startComplexProcessingOfFile()
can throw "a whole range of different exceptions" and you have to care
about more than two or three of them, I'd argue that it is broken.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-12-2009
On May 11, 10:43 pm, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Mon, 11 May 2009 01:52:15 -0700 (PDT),
> (E-Mail Removed) <(E-Mail Removed)> wrote:


> > I have the following incomplete code -


> > File file;
> > file.open(filePath);


> > try
> > {
> > someOneElsesApi::startComplexProcessingOfFile(file );
> > std::cout << "The file is now processed" << std::endl;


> Do you use std::endl here because you explicitly want flushing
> of cout at this point, or because you mistakenly think \n is
> not portable?


Or most likely, because it is the standard way of terminating a
line. (Standard in the sense of "usual or default practice".)
At least from what he's posted, there's no reason to assume that
the flush is causing a performance problem, so there's no reason
to not use std::endl.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-12-2009
* James Kanze:
> On May 11, 10:43 pm, Jorgen Grahn <(E-Mail Removed)> wrote:
>> On Mon, 11 May 2009 01:52:15 -0700 (PDT),
>> (E-Mail Removed) <(E-Mail Removed)> wrote:

>
>>> I have the following incomplete code -

>
>>> File file;
>>> file.open(filePath);

>
>>> try
>>> {
>>> someOneElsesApi::startComplexProcessingOfFile(file );
>>> std::cout << "The file is now processed" << std::endl;

>
>> Do you use std::endl here because you explicitly want flushing
>> of cout at this point, or because you mistakenly think \n is
>> not portable?

>
> Or most likely, because it is the standard way of terminating a
> line. (Standard in the sense of "usual or default practice".)
> At least from what he's posted, there's no reason to assume that
> the flush is causing a performance problem, so there's no reason
> to not use std::endl.


It's also debatable whether

#include <iostream>
int main() { std::cout << "Bah\n"; }

is guaranteed to produce any output at all.

I don't know (though I suspect answer is "no") and don't care, but anyone
recommending not using endl and criticizing others for using it should know and
be able to back it up with some quote from the standard.


Cheers,

- Alf

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! Just going there is good. Linking
to it is even better! Thanks in advance!
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      05-12-2009
In article <guban1$ci9$(E-Mail Removed)>, (E-Mail Removed) says...

[ ... ]

> It's also debatable whether
>
> #include <iostream>
> int main() { std::cout << "Bah\n"; }
>
> is guaranteed to produce any output at all.
>
> I don't know (though I suspect answer is "no") and don't care, but anyone
> recommending not using endl and criticizing others for using it should know and
> be able to back it up with some quote from the standard.


I don't see how there's any room for debate at all. See [lib.ios::Init]
(27.4.2.1.6). std::ios_base::Init is a class that (acts like it) keeps a
reference count to ensure that cin, cout, cerr, and clog (and wide
variants) are created once in a program that uses them, and flushed
before the program exits.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-12-2009
* Jerry Coffin:
> In article <guban1$ci9$(E-Mail Removed)>, (E-Mail Removed) says...
>
> [ ... ]
>
>> It's also debatable whether
>>
>> #include <iostream>
>> int main() { std::cout << "Bah\n"; }
>>
>> is guaranteed to produce any output at all.
>>
>> I don't know (though I suspect answer is "no") and don't care, but anyone
>> recommending not using endl and criticizing others for using it should know and
>> be able to back it up with some quote from the standard.

>
> I don't see how there's any room for debate at all. See [lib.ios::Init]
> (27.4.2.1.6). std::ios_base::Init is a class that (acts like it) keeps a
> reference count to ensure that cin, cout, cerr, and clog (and wide
> variants) are created once in a program that uses them, and flushed
> before the program exits.


Of course, you can provide a quote or reference to the place the standard
guarantees the creation of at least one such object?

And, what about e.g. an ofstream?


Cheers & hth.,

- Alf

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! Just going there is good. Linking
to it is even better! Thanks in advance!
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      05-12-2009
In article <guc9qa$5mg$(E-Mail Removed)>, (E-Mail Removed) says...

[ ... ]

> Of course, you can provide a quote or reference to the place the standard
> guarantees the creation of at least one such object?


Sort of, in 27.3/2. That's what actually creates cin, cout, etc. -- so
without it, the problem isn't going to be lack of output from the
program -- it's going to be extra output from the linker saying your
program has undefined externals, and then you'll get no executable at
all.

> And, what about e.g. an ofstream?


What about it? Do you mean: "Is all output that has been written to an
fstream required to be written to the external file?" If so, the answer
is basically yes. ~std::basic_filebuf() calls close() (§27.8.1.2/3).
Close flushes the output by calling overflow(EOF) if a put area exists
(§27.8.1.3/6). Of course, this assumes normal exit -- if the program
exits via abort() (for one example) buffers aren't flushed.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-13-2009
On May 12, 10:04 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:
> * James Kanze:
> > On May 11, 10:43 pm, Jorgen Grahn <(E-Mail Removed)> wrote:
> >> On Mon, 11 May 2009 01:52:15 -0700 (PDT),
> >> (E-Mail Removed) <(E-Mail Removed)> wrote:


> >>> I have the following incomplete code -


> >>> File file;
> >>> file.open(filePath);


> >>> try
> >>> {
> >>> someOneElsesApi::startComplexProcessingOfFile(file );
> >>> std::cout << "The file is now processed" << std::endl;


> >> Do you use std::endl here because you explicitly want flushing
> >> of cout at this point, or because you mistakenly think \n is
> >> not portable?


> > Or most likely, because it is the standard way of terminating a
> > line. (Standard in the sense of "usual or default practice".)
> > At least from what he's posted, there's no reason to assume that
> > the flush is causing a performance problem, so there's no reason
> > to not use std::endl.


> It's also debatable whether


> #include <iostream>
> int main() { std::cout << "Bah\n"; }


> is guaranteed to produce any output at all.


Since when? The standard guarantees that flush will be called
on all of the standard stream objects during a clean shutdown.
(There may be problems if you output to std::cout in the
destructor of a static object. The stream is guaranteed not to
be destructed, but you might have to manually ensure the flush
to ensure that data is actually output.)

Of course, one of my major arguments for using std::endl instead
of '\n', by default, is that, like it or not, not all shutdowns
are clean. And debugging is a lot easier if the output is
actually indicative of how far the program has gotten.

> I don't know (though I suspect answer is "no") and don't care,
> but anyone recommending not using endl and criticizing others
> for using it should know and be able to back it up with some
> quote from the standard.


It's more an engineering issue than a standards one. Basically,
std::endl is the "standard" way of terminating a line (standard
in the sense of "usual" or "accepted practice", not in the sense
of ISO/IEC 14882); replacing it with '\n' is an optimization.
Which shouldn't be undertaken prematurely.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Catching unhandled exceptions using HttpModules Amil Hanish ASP .Net 0 04-12-2006 11:51 PM
Catching exceptions in JSP when they occur in Servlets Mick Java 0 08-06-2003 01:12 PM
Re: Catching exceptions that are never thrown Adam Maass Java 5 07-22-2003 10:58 PM
Re: Catching exceptions that are never thrown Mike Schilling Java 2 07-16-2003 08:36 PM
Re: catching exceptions from web user controls Marina ASP .Net 2 07-08-2003 04:48 PM



Advertisments