www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: simple exception handling

reply "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/ 
Nov 04 2004
parent reply 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
Nov 04 2004
parent reply "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.
Nov 04 2004
parent "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,

 hate the way .NET throws a FileNotFound-exception when tyring to open a

 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.
Nov 05 2004