Daht.Sagitta.Core 8.1.0

Daht.Sagitta.Core

home / packages /

Functional paradigm abstractions for .NET

Table of contents

1. Installation
   • .NET command-line interface
   • Project file
   • Central package management
2. API
   • Root
   • Results
   • FAQ
3. License
4. Security policy
5. Code of conduct
6. Contributing guidelines
7. Contact

Installation

For information on all available versions, please see the NuGet or GitHub package registry

.NET command-line interface

dotnet add package 'Daht.Sagitta.Core' --version 'x.x.x'

For more information, please see here.

Top

Project file

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Daht.Sagitta.Core" Version="x.x.x" />
  </ItemGroup>
</Project>

For more information, please see here.

Top

Central package management

1. Directory.Packages.props file:

   <Project>
     <PropertyGroup>
       <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
     </PropertyGroup>
     <ItemGroup>
       <PackageVersion Include="Daht.Sagitta.Core" Version="x.x.x" />
     </ItemGroup>
   </Project>
   

2. Project file:

   <Project Sdk="Microsoft.NET.Sdk">
     <ItemGroup>
       <PackageReference Include="Daht.Sagitta.Core" />
     </ItemGroup>
   </Project>
   

For more information, please see here.

Top

API

Root

Structures intended to integrate with and extend existing modules.

Top

Results

Structures intended to encapsulate and manage both potential failure and expected success for a given action.

Top

FAQ

• When to use exceptions?
  • For exceptional, unpredictable, or non-deterministic situations (e.g., disk I/O failures, network timeouts, out-of-memory conditions).
  • For cases where local recovery is not possible or would compromise system integrity (e.g., corrupted state, violated invariants, missing critical resources).
  • When an error must be propagated beyond the local scope to enable stack unwinding or a global recovery strategy (e.g., transaction rollback, centralized cleanup, subsystem restart, escalation to another module).
• When not to use exceptions?
  • For predictable or expected scenarios (e.g., unavailable values, out-of-range values, invalid formats or patterns).
  • As a substitute for normal control flow (e.g., loop termination, flag checking, selecting alternate code paths).
  • In high-performance or latency-sensitive scenarios (e.g., tight loops, real-time processing, compute-intensive tasks).
• Why use Result<TFailure, TSuccess> and ValueResult<TFailure, TSuccess> instead of exceptions?
  • Safety: Minimizes side effects through consistent and deterministic control.
  • Efficiency: Eliminates the overhead associated with exception-based flow control.
  • Transparency: Explicitly and semantically exposes the state and intent of an operation.
  • Extensibility: Provides a flexible API to extend, adapt, and evolve processes.

Top

License

Licensed under the MIT License.

Top

Security policy

Please read and keep in mind our security policy.

Top

Code of conduct

Please read and follow our code of conduct.

Top

Contributing guidelines

Please read and follow our contributing guidelines.

Top

Contact

• LinkedIn
• Email (FOSS): daht.x.foss@gmail.com

Top