Hi again,

For many non-critical functions I often use the following prototype (C++):

bool somefunction( someparameters );

returning 'false' if anything goes wrong, 'true' if it did what you'd expect. It is adequate for most tasks like: bool OpenFile(filename), bool RemoveFromArray(element) etc..

Obviously exception handling provides a more extensible way to catch errors than a single boolean, but I find myself writing this code a lot:

bool somefunction( params )
{
  try {
    callsomecouldthatcanthrow();
    return true;
  } catch (...) {
    return false;
  }
}

...when using code that's using C++ exception-handling from code that's not written to handle exceptions, but will still work correctly if 'false' is returned.

My suggestion boils down to this: specifying which value to return from a function in case an exception is thrown.

Example syntax (I'm going out on a limb here):

bool somefunction( params ) catch(false)
{
  //... code that can throw exceptions
  return true;
}

This code would return 'false' in case of an exception. (The syntax is similar to using "throw" after a function declaration to specify which exceptions the function can throw.)

I know it's weird, but it might lower the threshold for using exception-handling in legacy code.

Too weird maybe?

-- 
Lionello.

-- Get the CACert root certificate (and a personal one) at http://cacert.org/

Lionello Lunesu wrote:
>
> bool somefunction( params ) catch(false)
> {
>   //... code that can throw exceptions
>   return true;
> }
> 
> This code would return 'false' in case of an exception. (The syntax is similar to using "throw" after a function declaration to specify which exceptions the function can throw.)

An interesting shorthand, but it has two problems.  First, the catch bit is part of the function declaration, not the definition, and that's an implementation detail the user doesn't need to know about.  Second, exceptions are typically thrown because something bad happened that may need to be fixed.  It's quite rare that any exception should be ignored outright.  Therefore, I don't see a strong argument for building support for an empty catch-all block into the language.


Sean

Hi..

> An interesting shorthand, but it has two problems.  First, the catch bit is part of the function declaration, not the definition, and that's an implementation detail the user doesn't need to know about.

Yes, you're definately right there.

> Second, exceptions are typically thrown because something bad happened that may need to be fixed.  It's quite rare that any exception should be ignored outright.  Therefore, I don't see a strong argument for building support for an empty catch-all block into the language.

Yes, I've heard that argument before, but don't really agree. For example, I hate the way .NET throws a FileNotFound-exception when tyring to open a file that doesn't exist. I still prefer the C "FILE *f = fopen(..); if (!f) {..}" to the try-catch in the file-open case.

I do agree though that there's no strong argument for my suggestion :-)

Lio.

"Lionello Lunesu" <lionello.lunesu@crystalinter.remove.com> wrote in message news:cmfat2$185k$1@digitaldaemon.com...
> Yes, I've heard that argument before, but don't really agree. For example,
I
> hate the way .NET throws a FileNotFound-exception when tyring to open a
file
> that doesn't exist. I still prefer the C "FILE *f = fopen(..); if (!f)
{..}"
> to the try-catch in the file-open case.

The idea is that if you're opening a file for reading, it should either succeed or fail in a way that cannot be ignored. However, if you're calling a function named doesFileExist(..), then it should indeed return a boolean.