Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)

[Hildo Biersma]

Johan Vromans wrote:

> You missed the point.
> 
> If you need 6+ lines of code for each elementary error check, this is
> what is going to happen (and it _does_ happen in almost every Java
> program I've seen):
> 
>     try {
>        open file
>        while read a record
>           process its contents
>        finalize file processing
>     }
>     catch (Exception e) {
>        error message: something went wrong
>     }
> 
> All the details about what went wrong, and were, are sacrificed since
> that would have required too much code, over and over again!

Yes, but... this is largely casued by the fact that Java requires you to
declare any uncaught parameters on your method specification, and this
tends to have a nasty oil-slick effect.

If you do it the C++ way, you can say:

  try {
    first_sub_that_throws_exceptions();
    second_sub_that_throws_exceptions();
  } catch {
    it went wrong 
  }

without cluttering up the interface of each and every sub.

Having said that, I would prefer the throwing of exceptions by built-in
functions to be optional, and changeable on a scope basis - so some
parts of my code can use an exception-based mechanism, other parts can
do return-value checking.  Rather like the way that DBI allows you to
set RaiseError on a database or statement handle and makes you do away
with error-checking for that handle - you just need to catch exceptions
around all uses of that handle.

Hildo