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!aioe.org!esY63sJc+00ALEoUyxrwTg.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Discriminants or Constructor Function for Limited Types Date: Mon, 9 May 2022 14:31:33 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <0b4ddd38-1f19-44fe-acd9-43a316ec9d29n@googlegroups.com> <7puf7h59k2e2ns66918i95s847na2b8num@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="54432"; posting-host="esY63sJc+00ALEoUyxrwTg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:63837 List-Id: On 2022-05-09 14:05, Doctor Who wrote: > On Mon, 9 May 2022 13:15:54 +0200, "Dmitry A. Kazakov" > 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? Yes, all this fully applies to local disks and filesystems. Just look how writing an SSD works. I think you could get better chances with magnetic drums from 60's. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de