Article

From:
To:
Greg Lorriman
Subject:
Re: Exceptions vs Error codes
Newsgroup:
borland.public.delphi.objectpascal

Re: Exceptions vs Error codes

"Greg Lorriman" <‚úČbigfoot.com> wrote in message
news:3b7848f8_1@dnews...
> I don;t think that I said that exceptions are for unanticipated
situations.

Noted your self-correction point, that's ok.
> My emphasis is on contracts being broken or, if you like, invalid
parameters.

It's really a style question. Let me try to describe the fundamental philosophical split between active exception usage and exception containment strategy as I see it; Beginning with the question: What is the fundamental 'mandate' of a program, a function, a procedure or a code block within a function/procedure?
1) In the exception-oriented world, it is to fulfil the nominal path ('mission') of a program. All circumstances which hinder this objective are regarded as exceptions and are handled (if at all) *outside* the program / function / procedure / block (by the caller). This means that by using exceptions one is shifting the responsibility to tackle error conditions to a higher level in the calling hierarchy. The program (or function within a program) (or block within a function) will have failed (exited abnormally), and the caller of that block or function or program will be responsible for calling the retry, if desired.
In this system, lower level functions or code blocks are intentionally unforgiving to any and all errors and anomalies, kicking responsibility for recovery up the ladder. It is the 'big boss' at the top (the Application exception handler, or in the worst case the program invocator) which decides how to proceed from there. Exceptions are ideal vehicles for such a system of error passing / handling.
2) In the exception-denial world (mine, for the time being), the mission of a program, a function, a procedure or a code block is to complete the normal path of execution /as far as possible, even when faced with anomalous conditions/; the primary responsibility for resolving error situations (invalid input, failed connections/allocations, timeouts, etc) is /contained within the function/ and thus common/anticipated error situations are *kept invisible* from the higher levels of the calling hierarchy for as long as possible (until the situation is locally deemed unrecoverable or further continuation is aborted by user intervention). This means that the program or function will be conditioned to complete its mission normally if at all possible, and the higher levels of the hierarchy can assume that when or if that program or function fails, the situation is truly unrecoverable.
In this system, each function takes maximum responsibility for ensuring the success of its mission, refusing to exit abnormally unless facing an unrecoverable anomaly (given their local scope and resources). If/when this happens, in my code they return an unmistakable error code (if possible) rather than an exception, since exceptions are really contrary to the philosophy of error containment.
[there, you've got me going again...<g>]
Kristofer
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Tue, 07 Feb 2023 04:55:50 UTC
Copyright © 2009-2023
HREF Tools Corp.