[dmd-internals] Throwing Errors

Walter Bright walter at digitalmars.com
Wed Mar 14 16:45:27 PDT 2012



On 3/14/2012 4:13 PM, Jesse Phillips wrote:
> It seems to me that everyone has an expectation that finalizers are
> attempted. And is my personal expectation. While Errors are not
> Exceptions they are being thrown via the Exception system and so it
> make sense to make a proper attempt at cleanup.

Errors are not recoverable - no cleanup is necessary.

> I will submit one piece of evidence toward this. OutOfMemoryError is
> valid to recover from and is only an error so that @nothrow and other
> restrictions do not apply to it, as it is always a potential problem.
> However not doing cleanup could prevent proper recover of OutOfMemory,
> and yes cleanup itself could fail, oh well.

OutOfMemory is deliberately made not recoverable, as I've almost never seen any 
application that can successfully recover from it. Making it non-recoverable 
also means that pure functions can allocate memory.


> Many times the Error comes from code which doesn't exist in release.
> This means it is safe to cleanup and do other operations, but you
> can't rely on it for program flow. This is where I like having the
> current state. It allows my environment to be returned to the original
> state (remove temporary files) without having to create an Error
> handling tree too.

If you're throwing recoverable exceptions in your debug code, make them derived 
from Exception, not Error.


More information about the dmd-internals mailing list