• Lionello Lunesu (38/38) Nov 04 2004 Hi again,
• Sean Kelly (9/18) Nov 04 2004 An interesting shorthand, but it has two problems. First, the catch bit...
• Lionello Lunesu (8/15) Nov 04 2004 Yes, I've heard that argument before, but don't really agree. For exampl...
• Walter (8/12) Nov 05 2004 I

"Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:

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/ 

Sean Kelly <sean f4.ca> writes:

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

"Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:

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.

"Walter" <newshound digitalmars.com> writes:

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