Prev: tostring
Next: about some drawing
From: aaron on 13 Jun 2010 21:56
Do you think an entire application (or at least each class) should have a
'final' try-catch block setup for any unexpected errors that could occur? If
so, how would you set this up? Would you 'throw' the errors to the final
exception block?
If not can you tell me why you would not have a final try-catch block?
From: Arne Vajhøj on 13 Jun 2010 22:22
On 13-06-2010 21:56, aaron wrote:
> Do you think an entire application (or at least each class) should have a
> 'final' try-catch block setup for any unexpected errors that could occur?

Application : yes
Each class : no

Many (read: most) classes will not know how to handle an exception.

> If
> so, how would you set this up? Would you 'throw' the errors to the final
> exception block?

Rethrowing is usually an API thing.

> If not can you tell me why you would not have a final try-catch block?

Most places.

See above.

Arne

From: Peter Duniho on 13 Jun 2010 23:50
aaron wrote:
> Do you think an entire application (or at least each class) should have a
> 'final' try-catch block setup for any unexpected errors that could occur? If
> so, how would you set this up? Would you 'throw' the errors to the final
> exception block?
> If not can you tell me why you would not have a final try-catch block?

There are different schools of thought. In general though, no…a "final
try-catch block" is not a universally useful or desirable feature.

For sure, it's not something that a _class_ would contain. For one,
what does it mean for there to be _a_ final try-catch block in a class?
A class is a collection of things, including methods, and usually more
than one that could be considered an "entry point" to the class.

Even looking at the application as a whole, where one could consider
there to be a single point of entry where it might make sense to catch
any exception, many will point out that not all exceptions make sense to
catch. Rarely, the program may encounter an exception that cannot be
recovered from, and so catching the exception may only make things
worse, or at the very least make a false implication to the user that
other than the error, everything is fine.

My feeling:

• For console applications, you might as well have a catch-all
top-level try/catch if you feel that makes sense. Provided you quit the
application immediately after catching and reporting the exception, and
there's no chance of the user proceeding under false pretenses, it
should be okay.

• For some GUI applications — in particular, those that are intended
to be basic "get the job done" tools, rather than full-fledged
user-friendly applications — it can simplify the error detection and
reporting code without causing any undue risk.

In other cases though, it seems to me that one should follow the model
that you should catch only those exceptions that were expected and which
you know you can safely recover from. For those exceptions only, it
often does make sense to have a top-level try/catch block, rather than
trying to process them deeper in the call stack. But that top-level
try/catch block should not be catching all exceptions. Only those that
you know would happen through normal usage of your program, and which
you know if they happen, your program can reliably recover from.


On a related note…

One thing I find unfortunate about .NET, and ironic given how much
easier .NET makes a lot of things, is how hard it can be to protect your
code from out-of-memory exceptions, which are probably the most common
type of "unrecoverable" exception that might occur. I put
"unrecoverable" in quotes, because in theory it's possible to write .NET
code that can safely recover from an out-of-memory exception (see
"critical execution region"), but in reality it's just not practical to
do so.

In unmanaged code, it's relatively simple to just pre-allocate
everything you need for error reporting, and then be assured that memory
allocations will only ever be attempted under the control of your own
program code. But the managed code environment has so many more
opportunities for memory allocations to occur implicitly on your behalf,
that it's hard to make sure you've made sure they won't happen in the
event of a memory allocation failure. And of course, if the system is
trying to allocate more memory just to report a memory allocation
failure, that can send the program into a spiral of out-of-memory errors
until the whole process just fails completely.

As such, out-of-memory exceptions are among those that are not generally
worth trying to recover from. I have included code to detect
out-of-memory in non-robust applications where some very large
allocation might be attempted and which could fail, even when there's
more than enough memory for everything else in the program to work. But
otherwise, it's usually just too much of a pain for it to be worth doing
correctly, and so an out-of-memory exception should be considered a
completely fatal error.

Pete
From: Arne Vajhøj on 14 Jun 2010 22:24
On 13-06-2010 23:50, Peter Duniho wrote:
> In unmanaged code, it's relatively simple to just pre-allocate
> everything you need for error reporting, and then be assured that memory
> allocations will only ever be attempted under the control of your own
> program code.

In C one has a good feeling for memory allocation.

In C++ especially if it is a bit complex then it can
be difficult to understand where all the allocations
are happening.

Arne
From: Peter Duniho on 15 Jun 2010 03:20
Arne Vajhøj wrote:
> On 13-06-2010 23:50, Peter Duniho wrote:
>> In unmanaged code, it's relatively simple to just pre-allocate
>> everything you need for error reporting, and then be assured that memory
>> allocations will only ever be attempted under the control of your own
>> program code.
>
> In C one has a good feeling for memory allocation.
>
> In C++ especially if it is a bit complex then it can
> be difficult to understand where all the allocations
> are happening.

Allocations can be abstracted in either C or C++.

However, in the error-handling context, my experience has been that it's
very simple to manage using either language. Just avoid trying to use
third-party components while detecting and reporting errors, and
likewise be careful about any internal code.

You can get yourself into trouble with practically any language. But,
IMHO the difference between C and C++ as memory management goes is tiny
compared to the difference between either and managed code. Managing
allocations, especially in the very limited context of detecting and
reporting errors, isn't really that hard (or at least, shouldn't be…the
design is probably overly complex if it is difficult to manage).

Pete
 | 
Pages: 1
Prev: tostring
Next: about some drawing