From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-65-14.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.6
Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Doctor Who <doc@tardis.org>
Newsgroups: comp.lang.ada
Subject: Re: Discriminants or Constructor Function for Limited Types
Date: Mon, 09 May 2022 14:05:09 +0200
Organization: A noiseless patient Spider
Message-ID: <nq0i7hhji09la6rujfl6vidqlag0ogb9ie@4ax.com>
References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> <t4ti4a$s1u$1@gioia.aioe.org> <t4v3f0$lgb$1@dont-email.me> <t4vsfi$jtb$1@gioia.aioe.org> <t51v2o$enb$1@dont-email.me> <t52nd4$vj2$1@gioia.aioe.org> <t54osn$hqf$1@dont-email.me> <t5619r$10bc$1@gioia.aioe.org> <t57a3o$e76$1@dont-email.me> <t57vgs$4su$1@gioia.aioe.org> <7puf7h59k2e2ns66918i95s847na2b8num@4ax.com> <t590fe$3ef$1@gioia.aioe.org> <sjqh7hh9pv2gqalco1s50l390454mc3hf3@4ax.com> <t5at5a$1j08$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="5a30916ed513fc626fe39b717d553480";
	logging-data="27667"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5B5Hoj+/yqdgctt2yhbn9"
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:iFvzaustxw0B6g4wG5WkJCJXxgg=
Xref: reader02.eternal-september.org comp.lang.ada:63836
List-Id: <comp.lang.ada>

On Mon, 9 May 2022 13:15:54 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On 2022-05-09 12:19, Doctor Who wrote:
>
>> if you do a check before write there is no need to rise and propagate
>> an exception.
>
>A bad idea.
>
>First it is an unnecessary overhead, because ultimately the check will 
>be repeated.
>
>Secondly it is technically impossible to do for a huge number of reasons:
>
>1. Too complex to do. The modern hardware and software does a lot of 
>bookkeeping, indexing, replicating, compression, encryption, the stuff 
>almost impossible to estimate or predict in advance.
>
>2. Unreliable due to racing conditions, volatile network states etc.
>
>3. Very expensive, e.g. in the case of a networking file system or a 
>database and the asynchronous nature of modern I/O subsystems. When you 
>write a file you normally do not wait for the operation completion. 
>Actual writing continues asynchronously to your application going 
>through dozens of stacks, caches, buffers, buses. If that fails you will 
>learn that later in a consequent operation unless you explicitly call 
>Flush or equivalent. Checking the state is a synchronous operation that 
>would have hundred- to thousandfold performance penalty.
>
>4. Just impossible like when dealing with a stream, a pipe line etc.
>
>As general design rules regarding exceptions consider:
>
>1. Never use return code.
>
>2. Never check anything non-trivial in advance.


we are talking about files, in a local disk right?