www.digitalmars.com         C & C++   DMDScript  

D - exception handling

reply imr1984 <imr1984_member pathlink.com> writes:
i have a few questions.

1. Suppose you run out of memory and so OutOfMemory is thrown. But all D
exceptions are heap allocated classes, so theoretically throwing the exception
could fail. Why is this not bad design?

2. What does the finally keyword in exception handling do? i cant find the
explanation in the spec.

3. How does excepion handling actually work? I mean in terms of the stack being
restored to the catch block when the exception is thrown.

Sorry ive just let loose the Qs here :)
Mar 17 2004
next sibling parent reply C <dont respond.com> writes:
2.) If an exception is caught, after all the catch blocks are analyzed, =

the finally block will be the last to execute and is guranteed to execut=
e.

void foo () { throw new Object; }
void main () {

     try { foo(); }
     catch ( Object o) { puts("object"); return; /* finnaly still gets =

executed */ }
     finally { puts("FINNALY"); }

}

3.) Here's a good article ,

http://www.codeproject.com/cpp/exceptionhandler.asp

On a side note (unwanted opinion ;) ), Im not really fond of exceptions.=
  =

I recognize their are useful for 'true' exceptions , but most of the tim=
e =

i see them as error handling , then suddenly you have to worry about =

making your code 'exception safe'.  I never understood what was wrong wi=
th =

returning an error code :S.

C

On Wed, 17 Mar 2004 16:53:26 +0000 (UTC), imr1984 =

<imr1984_member pathlink.com> wrote:

 i have a few questions.

 1. Suppose you run out of memory and so OutOfMemory is thrown. But all=
D
 exceptions are heap allocated classes, so theoretically throwing the =
 exception
 could fail. Why is this not bad design?

 2. What does the finally keyword in exception handling do? i cant find=
=
 the
 explanation in the spec.

 3. How does excepion handling actually work? I mean in terms of the =
 stack being
 restored to the catch block when the exception is thrown.

 Sorry ive just let loose the Qs here :)
-- = Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Mar 17 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
C schrieb:

 On a side note (unwanted opinion ;) ), Im not really fond of 
 exceptions.  I recognize their are useful for 'true' exceptions , but 
 most of the time i see them as error handling , then suddenly you have 
 to worry about making your code 'exception safe'.  I never understood 
 what was wrong with returning an error code :S.
Else you start making your code failure-unsafe, or at least it was in C. Recall from some cheapo book "Error handling left out for clarity. With it the code would be more than twice as long." While with exceptions, it's like less than 10%! In D we have a much better belance of features and the exception safety question from C++ shouldn't strike us in D except in most esoteric cases. Recall, GC calls destructors on objects. Nor would code become failure unsafe from a little of manual error handling where it may be due anyway, but no more than minimum. Sharp corners away. ;) -eye
Mar 17 2004
parent C <dont respond.com> writes:
 In D we have a much better belance of features and the exception safet=
y =
 question from C++ shouldn't strike us in D except in most esoteric cas=
es. Hmm does D's garbage collection completely eliminate the need for = exception safe code ? Does Java have any problems like C++'s? If so that would be awesome, I might have to finnaly give in and start = using exceptions :S. On Wed, 17 Mar 2004 19:08:17 +0100, Ilya Minkov <minkov cs.tum.edu> wrot= e:
 C schrieb:

 On a side note (unwanted opinion ;) ), Im not really fond of =
 exceptions.  I recognize their are useful for 'true' exceptions , but=
=
 most of the time i see them as error handling , then suddenly you hav=
e =
 to worry about making your code 'exception safe'.  I never understood=
=
 what was wrong with returning an error code :S.
Else you start making your code failure-unsafe, or at least it was in =
C. =
 Recall from some cheapo book "Error handling left out for clarity. Wit=
h =
 it the code would be more than twice as long." While with exceptions, =
 it's like less than 10%! In D we have a much better belance of feature=
s =
 and the exception safety question from C++ shouldn't strike us in D =
 except in most esoteric cases. Recall, GC calls destructors on objects=
. =
 Nor would code become failure unsafe from a little of manual error =
 handling where it may be due anyway, but no more than minimum. Sharp =
 corners away. ;)

 -eye
-- = D Newsgroup.
Mar 21 2004
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
imr1984 schrieb:
 i have a few questions.
 
 1. Suppose you run out of memory and so OutOfMemory is thrown. But all D
 exceptions are heap allocated classes, so theoretically throwing the exception
 could fail. Why is this not bad design?
Try to throw a not heap-allocated excepion in C++. ;) As the stack pointer is being raised, the exception data becomes invalid and can be overwritten by OS at will. DigitalMars compiler doesn't throw this exception, IIRC. I would think that there should be a global flag whether this excption is to be thrown, and (system-depandant) flags at which condition, such as less than 1 meg free, too much fragmentation and so on. Just before this exception is thrown, the flag is to be reset not to throw such exceptions any longer. This application working in an enviroment where such may happen, can take means, such as compact the heap and start anew, or unload something. I'm thinking of game consoles right now. BTW, i would like to know whether Walter has thought about how feasible D would be on a 32-bit system without MMU and with very limited memory? The current GC certainly not. Guys from Kallisti-OS crew have choked on MMU unit implementation. ;)
 2. What does the finally keyword in exception handling do? i cant find the
 explanation in the spec.
It is inherited from Java and Delphi. It allows you to do finalization tasks (close objects, free mem and such) regardless of whether an exception is thrown or not. I have done that in Delphi (naturally without except) a lot of times, it was really comfy there. And it's also good in Java due to complete lack of determenistic destruction. In D, it is just convenience when you don't want/need to use Auto objects.
 3. How does excepion handling actually work? I mean in terms of the stack being
 restored to the catch block when the exception is thrown.
Hmmmm... i'm not sure i can tell much about it, look after "stack unrolling" in the net if you are interested. I imagine there is a separate stack of "stack depth" values, where also except/finally blocks are registered, and it restores the stack pointer to a level, calls the block, and so on. However, i don't know how it is actually implemented. This may also work without a separate stack. The implementation also depends on the OS, since in Windows this is standardly done though SEH (Structured Exception Handling), on Linux i think though compiler-dependant means only.
 Sorry ive just let loose the Qs here :)
That's life. It is easier for someone to answer who knows than for you to search through unendless heaps of information. It's all not in the spec. -eye
Mar 17 2004
prev sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
 1. Suppose you run out of memory and so OutOfMemory is thrown. But all D
 exceptions are heap allocated classes, so theoretically throwing the
exception
 could fail. Why is this not bad design?
To solve this, the system should have a non-throwing allocator (which returns 0 instead) as well, to be used for allocating exception objects In addition, you could use an 'emergency allocator' which always makes sure it has at least enough memory to allocate an OutOfMemory exception from Alternatively, you might use one global statically allocated OutOfMemory exception object; this works if you don't need to remember any context-specific information, such as stack traces
Mar 18 2004