Daht.Sagitta.Core 8.0.1

Daht.Sagitta.Core

home / packages /

Functional paradigm abstractions for .NET - Core

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?
  • Exceptional, unpredictable, or non-deterministic situations (e.g., disk I/O failures, network timeouts, out-of-memory conditions).
  • When 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 API/module).
• When not to use exceptions?
  • Predictable or expected scenarios (e.g., business-rule violations, parameter validation, boundary checks, foreseeable edge cases).
  • As a substitute for normal control flow (e.g., loop termination, flag checking, selecting alternate code paths).
  • In high-performance and latency-sensitive scenarios (e.g., tight loops, real-time processing, compute-intensive tasks).
• Why Result<TFailure, TSuccess> and ValueResult<TFailure, TSuccess>?
  • Exceptions are expensive, because throwing and catching requires constructing complex objects, capturing a full stack trace, and unwinding the call stack.
  • Exceptions are intended for exceptional and unpredictable situations and should not be used for regular control flow or business-rule enforcement.

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