ZcashLightClientKit/Sources/ZcashLightClientKit/Error/ZcashErrorCodeDefinition.swift

695 lines
35 KiB
Swift
Raw Normal View History

[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
//
// ZcashErrorDefinition.swift
//
//
// Created by Michal Fousek on 10.04.2023.
//
import Foundation
// swiftlint:disable identifier_name
/*
This enum won't every be directly used in the code. It is just definition of errors and it used as source for Sourcery. And the files used in the
code are then generated. Check `ZcashError` and `ZcashErrorCode`.
Please pay attention how each error is defined here. Important part is to raw code for each error. And it's important to use /// for the
documentation and only // for the sourcery command.
First line of documentation for each error will be used in automatically generated `message` property.
Error code should always start with `Z` letter. Then there should be 0-4 letters that marks in which part of the SDK is the code used. And then 4
numbers. This is suggestion to keep some order when it comes to error codes. Each code must be unique. `ZcashErrorCode` enum is generated from these
codes. So if the code isn't unique generated code won't compile.
*/
enum ZcashErrorDefinition {
/// Some error happened that is not handled as `ZcashError`. All errors in the SDK are (should be) `ZcashError`.
/// This case is ideally not contructed directly or thrown by any SDK function, rather it's a wrapper for case clients expect ZcashErrot and want to pass it to a function/enum.
/// If this is the case, use `toZcashError()` extension of Error. This helper avoids to end up with Optional handling.
// sourcery: code="ZUNKWN0001"
case unknown(_ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - Initializer
/// Updating of paths in `Initilizer` according to alias failed.
// sourcery: code="ZINIT0001"
case initializerCantUpdateURLWithAlias(_ url: URL)
/// Alias used to create this instance of the `SDKSynchronizer` is already used by other instance.
// sourcery: code="ZINIT0002"
case initializerAliasAlreadyInUse(_ alias: ZcashSynchronizerAlias)
/// Object on disk at `generalStorageURL` path exists. But it file not directory.
// sourcery: code="ZINIT0003"
case initializerGeneralStorageExistsButIsFile(_ generalStorageURL: URL)
/// Can't create directory at `generalStorageURL` path.
// sourcery: code="ZINIT0004"
case initializerGeneralStorageCantCreate(_ generalStorageURL: URL, _ error: Error)
/// Can't set `isExcludedFromBackup` flag to `generalStorageURL`.
// sourcery: code="ZINIT0005"
case initializerCantSetNoBackupFlagToGeneralStorageURL(_ generalStorageURL: URL, _ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - LightWalletService
/// Unknown GRPC Service error
// sourcery: code="ZSRVC0001"
case serviceUnknownError(_ error: Error)
/// LightWalletService.getInfo failed.
// sourcery: code="ZSRVC0002"
case serviceGetInfoFailed(_ error: LightWalletServiceError)
/// LightWalletService.latestBlock failed.
// sourcery: code="ZSRVC0003"
case serviceLatestBlockFailed(_ error: LightWalletServiceError)
/// LightWalletService.latestBlockHeight failed.
// sourcery: code="ZSRVC0004"
case serviceLatestBlockHeightFailed(_ error: LightWalletServiceError)
/// LightWalletService.blockRange failed.
// sourcery: code="ZSRVC0005"
case serviceBlockRangeFailed(_ error: LightWalletServiceError)
/// LightWalletService.submit failed.
// sourcery: code="ZSRVC0006"
case serviceSubmitFailed(_ error: LightWalletServiceError)
/// LightWalletService.fetchTransaction failed.
// sourcery: code="ZSRVC0007"
case serviceFetchTransactionFailed(_ error: LightWalletServiceError)
/// LightWalletService.fetchUTXOs failed.
// sourcery: code="ZSRVC0008"
case serviceFetchUTXOsFailed(_ error: LightWalletServiceError)
/// LightWalletService.blockStream failed.
// sourcery: code="ZSRVC0000"
case serviceBlockStreamFailed(_ error: LightWalletServiceError)
/// LightWalletService.getSubtreeRoots failed.
// sourcery: code="ZSRVC0009"
case serviceSubtreeRootsStreamFailed(_ error: LightWalletServiceError)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: SQLite connection
/// SimpleConnectionProvider init of Connection failed.
// sourcery: code="ZSCPC0001"
case simpleConnectionProvider(_ error: Error)
// MARK: - Sapling parameters download
/// Downloaded file with sapling spending parameters isn't valid.
// sourcery: code="ZSAPP0001"
case saplingParamsInvalidSpendParams
/// Downloaded file with sapling output parameters isn't valid.
// sourcery: code="ZSAPP0002"
case saplingParamsInvalidOutputParams
/// Failed to download sapling parameters file
/// - `error` is download error.
/// - `downloadURL` is URL from which was file downloaded.
// sourcery: code="ZSAPP0003"
case saplingParamsDownload(_ error: Error, _ downloadURL: URL)
/// Failed to move sapling parameters file to final destination after download.
/// - `error` is move error.
/// - `downloadURL` is URL from which was file downloaded.
/// - `destination` is filesystem URL pointing to location where downloaded file should be moved.
// sourcery: code="ZSAPP0004"
case saplingParamsCantMoveDownloadedFile(_ error: Error, _ downloadURL: URL, _ destination: URL)
// MARK: - BlockDAO
/// SQLite query failed when fetching block information from database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZBDAO0001"
case blockDAOBlock(_ sqliteError: Error)
/// Fetched block information from DB but can't decode them.
/// - `error` is decoding error.
// sourcery: code="ZBDAO0002"
case blockDAOCantDecode(_ error: Error)
/// SQLite query failed when fetching height of the latest block from the database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZBDAO0003"
case blockDAOLatestBlockHeight(_ sqliteError: Error)
/// SQLite query failed when fetching the latest block from the database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZBDAO0004"
case blockDAOLatestBlock(_ sqliteError: Error)
/// Fetched latest block information from DB but can't decode them.
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
/// - `error` is decoding error.
// sourcery: code="ZBDAO0005"
case blockDAOLatestBlockCantDecode(_ error: Error)
/// SQLite query failed when fetching the first unenhanced block from the database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZBDAO0006"
case blockDAOFirstUnenhancedHeight(_ sqliteError: Error)
/// Fetched unenhanced block information from DB but can't decode them.
/// - `error` is decoding error.
// sourcery: code="ZBDAO0007"
case blockDAOFirstUnenhancedCantDecode(_ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - Rust
/// Error from rust layer when calling ZcashRustBackend.createAccount
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0001"
case rustCreateAccount(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.createToAddress
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0002"
case rustCreateToAddress(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.decryptAndStoreTransaction
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0003"
case rustDecryptAndStoreTransaction(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.getBalance
/// - `account` is account passed to ZcashRustBackend.getBalance.
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0004"
case rustGetBalance(_ account: Int, _ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.getCurrentAddress
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0005"
case rustGetCurrentAddress(_ rustError: String)
/// Unified address generated by rust layer is invalid when calling ZcashRustBackend.getCurrentAddress
// sourcery: code="ZRUST0006"
case rustGetCurrentAddressInvalidAddress
/// Error from rust layer when calling ZcashRustBackend.getNearestRewindHeight
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0007"
case rustGetNearestRewindHeight(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.getNextAvailableAddress
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0008"
case rustGetNextAvailableAddress(_ rustError: String)
/// Unified address generated by rust layer is invalid when calling ZcashRustBackend.getNextAvailableAddress
// sourcery: code="ZRUST0009"
case rustGetNextAvailableAddressInvalidAddress
/// account parameter is lower than 0 when calling ZcashRustBackend.getTransparentBalance
/// - `account` is account passed to ZcashRustBackend.getTransparentBalance.
// sourcery: code="ZRUST0010"
case rustGetTransparentBalanceNegativeAccount(_ account: Int)
/// Error from rust layer when calling ZcashRustBackend.getTransparentBalance
/// - `account` is account passed to ZcashRustBackend.getTransparentBalance.
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0011"
case rustGetTransparentBalance(_ account: Int, _ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.getVerifiedBalance
/// - `account` is account passed to ZcashRustBackend.getVerifiedBalance.
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0012"
case rustGetVerifiedBalance(_ account: Int, _ rustError: String)
/// account parameter is lower than 0 when calling ZcashRustBackend.getVerifiedTransparentBalance
/// - `account` is account passed to ZcashRustBackend.getVerifiedTransparentBalance.
// sourcery: code="ZRUST0013"
case rustGetVerifiedTransparentBalanceNegativeAccount(_ account: Int)
/// Error from rust layer when calling ZcashRustBackend.getVerifiedTransparentBalance
/// - `account` is account passed to ZcashRustBackend.getVerifiedTransparentBalance.
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0014"
case rustGetVerifiedTransparentBalance(_ account: Int, _ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.initDataDb
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0015"
case rustInitDataDb(_ rustError: String)
/// Any of the viewing keys passed to the ZcashRustBackend.initAccountsTable method contains null bytes before end
// sourcery: code="ZRUST0016"
case rustInitAccountsTableViewingKeyCotainsNullBytes
/// Any of the viewing keys passed to the ZcashRustBackend.initAccountsTable method isn't valid
// sourcery: code="ZRUST0017"
case rustInitAccountsTableViewingKeyIsInvalid
/// Error from rust layer when calling ZcashRustBackend.initAccountsTable
// sourcery: code="ZRUST0018"
case rustInitAccountsTableDataDbNotEmpty
/// Error from rust layer when calling ZcashRustBackend.initAccountsTable
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0019"
case rustInitAccountsTable(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.initBlockMetadataDb
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0020"
case rustInitBlockMetadataDb(_ rustError: String)
/// Unable to allocate memory required to write blocks when calling ZcashRustBackend.writeBlocksMetadata
// sourcery: code="ZRUST0021"
case rustWriteBlocksMetadataAllocationProblem
/// Error from rust layer when calling ZcashRustBackend.writeBlocksMetadata
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0022"
case rustWriteBlocksMetadata(_ rustError: String)
/// hash passed to the ZcashRustBackend.initBlocksTable method contains null bytes before end
// sourcery: code="ZRUST0023"
case rustInitBlocksTableHashContainsNullBytes
/// saplingTree passed to the ZcashRustBackend.initBlocksTable method contains null bytes before end
// sourcery: code="ZRUST0024"
case rustInitBlocksTableSaplingTreeContainsNullBytes
/// Error from rust layer when calling ZcashRustBackend.initBlocksTable
// sourcery: code="ZRUST0025"
case rustInitBlocksTableDataDbNotEmpty
/// Error from rust layer when calling ZcashRustBackend.initBlocksTable
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0026"
case rustInitBlocksTable(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.listTransparentReceivers
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0027"
case rustListTransparentReceivers(_ rustError: String)
/// Transparent receiver generated by rust layer is invalid when calling ZcashRustBackend.listTransparentReceivers
// sourcery: code="ZRUST0028"
case rustListTransparentReceiversInvalidAddress
/// Error from rust layer when calling ZcashRustBackend.putUnspentTransparentOutput
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0029"
case rustPutUnspentTransparentOutput(_ rustError: String)
/// Error unrelated to chain validity from rust layer when calling ZcashRustBackend.validateCombinedChain
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0030"
case rustValidateCombinedChainValidationFailed(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.rewindToHeight
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0032"
case rustRewindToHeight(_ height: Int32, _ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.rewindCacheToHeight
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0033"
case rustRewindCacheToHeight(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.scanBlocks
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0034"
case rustScanBlocks(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.shieldFunds
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0035"
case rustShieldFunds(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.consensusBranchIdFor
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0036"
case rustNoConsensusBranchId(_ height: Int32)
/// address passed to the ZcashRustBackend.receiverTypecodesOnUnifiedAddress method contains null bytes before end
/// - `address` is address passed to ZcashRustBackend.receiverTypecodesOnUnifiedAddress.
// sourcery: code="ZRUST0037"
case rustReceiverTypecodesOnUnifiedAddressContainsNullBytes(_ address: String)
/// Error from rust layer when calling ZcashRustBackend.receiverTypecodesOnUnifiedAddress
// sourcery: code="ZRUST0038"
case rustRustReceiverTypecodesOnUnifiedAddressMalformed
/// Error from rust layer when calling ZcashRustBackend.deriveUnifiedSpendingKey
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0039"
case rustDeriveUnifiedSpendingKey(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.deriveUnifiedFullViewingKey
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0040"
case rustDeriveUnifiedFullViewingKey(_ rustError: String)
/// Viewing key derived by rust layer is invalid when calling ZcashRustBackend.deriveUnifiedFullViewingKey
// sourcery: code="ZRUST0041"
case rustDeriveUnifiedFullViewingKeyInvalidDerivedKey
/// Error from rust layer when calling ZcashRustBackend.getSaplingReceiver
/// - `address` is address passed to ZcashRustBackend.getSaplingReceiver.
// sourcery: code="ZRUST0042"
case rustGetSaplingReceiverInvalidAddress(_ address: UnifiedAddress)
/// Sapling receiver generated by rust layer is invalid when calling ZcashRustBackend.getSaplingReceiver
// sourcery: code="ZRUST0043"
case rustGetSaplingReceiverInvalidReceiver
/// Error from rust layer when calling ZcashRustBackend.getTransparentReceiver
/// - `address` is address passed to ZcashRustBackend.getTransparentReceiver.
// sourcery: code="ZRUST0044"
case rustGetTransparentReceiverInvalidAddress(_ address: UnifiedAddress)
/// Transparent receiver generated by rust layer is invalid when calling ZcashRustBackend.getTransparentReceiver
// sourcery: code="ZRUST0045"
case rustGetTransparentReceiverInvalidReceiver
/// Unable to allocate memory required to write blocks when calling ZcashRustBackend.putSaplingSubtreeRoots
/// sourcery: code="ZRUST0046"
case rustPutSaplingSubtreeRootsAllocationProblem
/// Error from rust layer when calling ZcashRustBackend.putSaplingSubtreeRoots
/// - `rustError` contains error generated by the rust layer.
/// sourcery: code="ZRUST0047"
case rustPutSaplingSubtreeRoots(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.updateChainTip
/// - `rustError` contains error generated by the rust layer.
/// sourcery: code="ZRUST0048"
case rustUpdateChainTip(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.suggestScanRanges
/// - `rustError` contains error generated by the rust layer.
/// sourcery: code="ZRUST0049"
case rustSuggestScanRanges(_ rustError: String)
/// Invalid transaction ID length when calling ZcashRustBackend.getMemo. txId must be 32 bytes.
// sourcery: code="ZRUST0050"
case rustGetMemoInvalidTxIdLength
/// Error from rust layer when calling ZcashRustBackend.getScanProgress
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0051"
case rustGetScanProgress(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.fullyScannedHeight
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0052"
case rustFullyScannedHeight(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.maxScannedHeight
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0053"
case rustMaxScannedHeight(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.latestCachedBlockHeight
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0054"
case rustLatestCachedBlockHeight(_ rustError: String)
/// Rust layer's call ZcashRustBackend.getScanProgress returned values that after computation are outside of allowed range 0-100%.
/// - `progress` value reported
// sourcery: code="ZRUST0055"
case rustScanProgressOutOfRange(_ progress: String)
/// Error from rust layer when calling ZcashRustBackend.getWalletSummary
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0056"
case rustGetWalletSummary(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0057"
case rustProposeTransferFromURI(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0058"
case rustListAccounts(_ rustError: String)
/// Error from rust layer when calling ZcashRustBackend.rustIsSeedRelevantToAnyDerivedAccount
/// - `rustError` contains error generated by the rust layer.
// sourcery: code="ZRUST0059"
case rustIsSeedRelevantToAnyDerivedAccount(_ rustError: String)
2024-03-28 07:23:49 -07:00
/// Unable to allocate memory required to write blocks when calling ZcashRustBackend.putOrchardSubtreeRoots
/// sourcery: code="ZRUST0060"
case rustPutOrchardSubtreeRootsAllocationProblem
/// Error from rust layer when calling ZcashRustBackend.putOrchardSubtreeRoots
/// - `rustError` contains error generated by the rust layer.
/// sourcery: code="ZRUST0061"
case rustPutOrchardSubtreeRoots(_ rustError: String)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - Account DAO
/// SQLite query failed when fetching all accounts from the database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZADAO0001"
case accountDAOGetAll(_ sqliteError: Error)
/// Fetched accounts from SQLite but can't decode them.
/// - `error` is decoding error.
// sourcery: code="ZADAO0002"
case accountDAOGetAllCantDecode(_ error: Error)
/// SQLite query failed when seaching for accounts in the database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZADAO0003"
case accountDAOFindBy(_ sqliteError: Error)
/// Fetched accounts from SQLite but can't decode them.
/// - `error` is decoding error.
// sourcery: code="ZADAO0004"
case accountDAOFindByCantDecode(_ error: Error)
/// Object passed to update() method conforms to `AccountEntity` protocol but isn't exactly `Account` type.
// sourcery: code="ZADAO0005"
case accountDAOUpdateInvalidAccount
/// SQLite query failed when updating account in the database.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZADAO0006"
case accountDAOUpdate(_ sqliteError: Error)
/// Update of the account updated 0 rows in the database. One row should be updated.
// sourcery: code="ZADAO0007"
case accountDAOUpdatedZeroRows
// MARK: - Block storage
/// Failed to write block to disk.
// sourcery: code="ZBLRP00001"
case blockRepositoryWriteBlock(_ block: ZcashCompactBlock, _ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
/// Failed to get filename for the block from file URL.
// sourcery: code="ZBLRP0002"
case blockRepositoryGetFilename(_ url: URL)
/// Failed to parse block height from filename.
// sourcery: code="ZBLRP0003"
case blockRepositoryParseHeightFromFilename(_ filename: String)
/// Failed to remove existing block from disk.
// sourcery: code="ZBLRP0004"
case blockRepositoryRemoveExistingBlock(_ url: URL, _ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
/// Failed to get filename and information if url points to directory from file URL.
// sourcery: code="ZBLRP0005"
case blockRepositoryGetFilenameAndIsDirectory(_ url: URL)
/// Failed to create blocks cache directory.
// sourcery: code="ZBLRP0006"
case blockRepositoryCreateBlocksCacheDirectory(_ url: URL, _ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
/// Failed to read content of directory.
// sourcery: code="ZBLRP0007"
case blockRepositoryReadDirectoryContent(_ url: URL, _ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
/// Failed to remove block from disk after rewind operation.
// sourcery: code="ZBLRP0008"
case blockRepositoryRemoveBlockAfterRewind(_ url: URL, _ error: Error)
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
/// Failed to remove blocks cache directory while clearing storage.
// sourcery: code="ZBLRP0009"
case blockRepositoryRemoveBlocksCacheDirectory(_ url: URL, _ error: Error)
/// Failed to remove block from cache when clearing cache up to some height.
// sourcery: code="ZBLRP0010"
case blockRepositoryRemoveBlockClearingCache(_ url: URL, _ error: Error)
// MARK: - Block Download
/// Trying to download blocks before sync range is set in `BlockDownloaderImpl`. This means that download stream is not created and download cant' start.
// sourcery: code="ZBDWN0001"
case blockDownloadSyncRangeNotSet
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - BlockDownloaderService
/// Stream downloading the given block range failed.
// sourcery: code="ZBDSEO0001"
case blockDownloaderServiceDownloadBlockRange(_ error: Error)
// MARK: - Transaction Entity / ZcashTransaction
/// Initialization of `ZcashTransaction.Overview` failed.
// sourcery: code="ZTEZT0001"
case zcashTransactionOverviewInit(_ error: Error)
/// Initialization of `ZcashTransaction.Received` failed.
// sourcery: code="ZTEZT0002"
case zcashTransactionReceivedInit(_ error: Error)
/// Initialization of `ZcashTransaction.Sent` failed.
// sourcery: code="ZTEZT0003"
case zcashTransactionSentInit(_ error: Error)
[#1001] Remove PendingDb in favor of `v_transactions` and `v_tx_output` Views (#1001) Removes `PendingTransactionEntity` and all of its related components. Pending items are still tracked and visualized by the existing APIs but they are retrieved from the `TransactionRepository` instead by returning `ZcashTransaction.Overview` instead. `pendingDbURL` is removed from every place it was required. Its deletion is responsibility of wallet developers. `ClearedTransactions` are now just `transactions`. `MigrationManager` is deleted. Now all migrations are in charge of the rust welding layer. `PendingTransactionDao.swift` is removed. Implementation of `AccountEntity` called `Account` is now `DbAccount` `ZcashTransaction.Overview` can be checked for "pending-ness" by calling `.isPending(latestHeight:)` latest height must be provided so that minedHeight can be compared with the lastest and the `defaultStaleTolerance` constant. `TransactionRecipient` is now a public type. protocol `PendingTransactionRepository` is removed. `TransactionManagerError` and `PersistentTransactionManager` are deleted. `OutboundTransactionManager` is deleted and replaced by `TransactionEncoder` which now incorporates `submit(encoded:)` functionality `WalletTransactionEncoder` now uses a `LightWalletService` to submit the encoded transactions. Add changelog changes Delete references to PendingDb from tests and documentation. Fixes some typos. Adds the ability to trace transaction repository SQL queries from test Fix rebase conflicts and generate code [#837] Memo tests regarding transparent address Closes #837 Add model for transaction output Point to FFI branch Fix issue where sync wouldn't resume after wipe. Becasue GRPC channel would be closed Fix Tests Fix testPendingTransactionMinedHeightUpdated Fix testLastStates [#921] Fix broken SynchronizerDarksideTests Add ZcashTransaction.Output API to Synchronizer Changelog + comment fix Add Assertions for transaction outputs and recipients Point to FFI 0.3.1 Fix Demo App Compiler errors Fix Demo App Compiler errors fix cacheDb warnings Fix Tests and compiler errors of rebase build demo app Remove `ZcashTransaction.Sent` and `.Received`. Add `.State` and tests Fix SPM warning PR Suggestions Removes errors that are not used anymore fix warnings
2023-05-05 10:30:47 -07:00
/// Initialization of `ZcashTransaction.Output` failed.
// sourcery: code="ZTEZT0004"
case zcashTransactionOutputInit(_ error: Error)
/// Initialization of `ZcashTransaction.Output` failed because there an inconsistency in the output recipient.
// sourcery: code="ZTEZT0005"
case zcashTransactionOutputInconsistentRecipient
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - Transaction Repository
/// Entity not found in the database, result of `createEntity` execution.
// sourcery: code="ZTREE0001"
case transactionRepositoryEntityNotFound
/// `Find` call is missing fields, required fields are transaction `index` and `blockTime`.
// sourcery: code="ZTREE0002"
case transactionRepositoryTransactionMissingRequiredFields
/// Counting all transactions failed.
// sourcery: code="ZTREE0003"
case transactionRepositoryCountAll(_ error: Error)
/// Counting all unmined transactions failed.
// sourcery: code="ZTREE0004"
case transactionRepositoryCountUnmined(_ error: Error)
/// Execution of a query failed.
// sourcery: code="ZTREE0005"
case transactionRepositoryQueryExecute(_ error: Error)
/// Finding memos in the database failed.
// sourcery: code="ZTREE0006"
case transactionRepositoryFindMemos(_ error: Error)
// MARK: - ZcashCompactBlock
/// Can't encode `ZcashCompactBlock` object.
// sourcery: code="ZCMPB0001"
case compactBlockEncode(_ error: Error)
// MARK: - Memo
/// Invalid UTF-8 Bytes where detected when attempting to create a MemoText.
// sourcery: code="ZMEMO0001"
case memoTextInvalidUTF8
/// Trailing null-bytes were found when attempting to create a MemoText.
// sourcery: code="ZMEMO0002"
case memoTextInputEndsWithNullBytes
/// The resulting bytes provided are too long to be stored as a MemoText.
// sourcery: code="ZMEMO0003"
case memoTextInputTooLong(_ length: Int)
/// The resulting bytes provided are too long to be stored as a MemoBytes.
// sourcery: code="ZMEMO0004"
case memoBytesInputTooLong(_ length: Int)
/// Invalid UTF-8 Bytes where detected when attempting to convert MemoBytes to Memo.
// sourcery: code="ZMEMO0005"
case memoBytesInvalidUTF8
// MARK: - Checkpoint
/// Failed to load JSON with checkpoint from disk.
// sourcery: code="ZCHKP0001"
case checkpointCantLoadFromDisk(_ error: Error)
/// Failed to decode `Checkpoint` object.
// sourcery: code="ZCHKP0002"
case checkpointDecode(_ error: Error)
// MARK: - DerivationTool
/// Invalid account when trying to derive spending key
// sourcery: code="ZDRVT0001"
case derivationToolSpendingKeyInvalidAccount
// MARK: - UnspentTransactionOutputDAO
/// Creation of the table for unspent transaction output failed.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZUTOD0001"
case unspentTransactionOutputDAOCreateTable(_ sqliteError: Error)
/// SQLite query failed when storing unspent transaction output.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZUTOD0002"
case unspentTransactionOutputDAOStore(_ sqliteError: Error)
/// SQLite query failed when removing all the unspent transation outputs.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZUTOD0003"
case unspentTransactionOutputDAOClearAll(_ sqliteError: Error)
/// Fetched information about unspent transaction output from the DB but it can't be decoded to `UTXO` object.
/// - `error` decoding error.
// sourcery: code="ZUTOD0004"
case unspentTransactionOutputDAOGetAllCantDecode(_ error: Error)
/// SQLite query failed when getting all the unspent transation outputs.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZUTOD0005"
case unspentTransactionOutputDAOGetAll(_ sqliteError: Error)
/// SQLite query failed when getting balance.
/// - `sqliteError` is error produced by SQLite library.
// sourcery: code="ZUTOD0006"
case unspentTransactionOutputDAOBalance(_ sqliteError: Error)
// MARK: - WalletTypes
/// Can't create `SaplingExtendedSpendingKey` because input is invalid.
// sourcery: code="ZWLTP0001"
case spendingKeyInvalidInput
/// Can't create `UnifiedFullViewingKey` because input is invalid.
// sourcery: code="ZWLTP0002"
case unifiedFullViewingKeyInvalidInput
/// Can't create `SaplingExtendedFullViewingKey` because input is invalid.
// sourcery: code="ZWLTP0003"
case extetendedFullViewingKeyInvalidInput
/// Can't create `TransparentAddress` because input is invalid.
// sourcery: code="ZWLTP0004"
case transparentAddressInvalidInput
/// Can't create `SaplingAddress` because input is invalid.
// sourcery: code="ZWLTP0005"
case saplingAddressInvalidInput
/// Can't create `UnifiedAddress` because input is invalid.
// sourcery: code="ZWLTP0006"
case unifiedAddressInvalidInput
/// Can't create `Recipient` because input is invalid.
// sourcery: code="ZWLTP0007"
case recipientInvalidInput
// MARK: - WalletTransactionEncoder
/// WalletTransactionEncoder wants to create transaction but files with sapling parameters are not present on disk.
// sourcery: code="ZWLTE0001"
case walletTransEncoderCreateTransactionMissingSaplingParams
/// WalletTransactionEncoder wants to shield funds but files with sapling parameters are not present on disk.
// sourcery: code="ZWLTE0002"
case walletTransEncoderShieldFundsMissingSaplingParams
// MARK: - Zatoshi
/// Initiatilzation fo `Zatoshi` from a decoder failed.
// sourcery: code="ZTSHO0001"
case zatoshiDecode(_ error: Error)
/// Encode of `Zatoshi` failed.
// sourcery: code="ZTSHO0002"
case zatoshiEncode(_ error: Error)
// MARK: - UTXOFetcher
/// Awaiting transactions from the stream failed.
// sourcery: code="ZUTXO0001"
case unspentTransactionFetcherStream(_ error: Error)
// MARK: - CompactBlockProcessor
/// CompactBlockProcessor was started with an invalid configuration.
// sourcery: code="ZCBPEO0001"
case compactBlockProcessorInvalidConfiguration
/// CompactBlockProcessor was set up with path but that location couldn't be reached.
// sourcery: code="ZCBPEO0002"
case compactBlockProcessorMissingDbPath(_ path: String)
/// Data Db file couldn't be initialized at path.
// sourcery: code="ZCBPEO0003"
case compactBlockProcessorDataDbInitFailed(_ path: String)
/// There's a problem with the network connection.
// sourcery: code="ZCBPEO0004"
case compactBlockProcessorConnection(_ underlyingError: Error)
/// Error on gRPC happened.
// sourcery: code="ZCBPEO0005"
case compactBlockProcessorGrpcError(statusCode: Int, message: String)
/// Network connection timeout.
// sourcery: code="ZCBPEO0006"
case compactBlockProcessorConnectionTimeout
/// Compact Block failed and reached the maximum amount of retries it was set up to do.
// sourcery: code="ZCBPEO0007"
case compactBlockProcessorMaxAttemptsReached(_ attempts: Int)
/// Unspecified error occured.
// sourcery: code="ZCBPEO0008"
case compactBlockProcessorUnspecified(_ underlyingError: Error)
/// Critical error occured.
// sourcery: code="ZCBPEO0009"
case compactBlockProcessorCritical
/// Invalid Account.
// sourcery: code="ZCBPEO0010"
case compactBlockProcessorInvalidAccount
/// The remote server you are connecting to is publishing a different branch ID than the one your App is expecting This could be caused by your App being out of date or the server you are connecting you being either on a different network or out of date after a network upgrade.
// sourcery: code="ZCBPEO0011"
case compactBlockProcessorWrongConsensusBranchId(expectedLocally: ConsensusBranchID, found: ConsensusBranchID)
/// A server was reached, but it's targeting the wrong network Type. Make sure you are pointing to the right server.
// sourcery: code="ZCBPEO0012"
case compactBlockProcessorNetworkMismatch(expected: NetworkType, found: NetworkType)
/// A server was reached, it's showing a different sapling activation. Are you sure you are pointing to the right server?
// sourcery: code="ZCBPEO0013"
case compactBlockProcessorSaplingActivationMismatch(expected: BlockHeight, found: BlockHeight)
/// when the given URL is the same URL than the one provided as `self.fsBlockDbRoot` assuming that's a programming error being the `legacyCacheDbURL` a sqlite database file and not a directory
// sourcery: code="ZCBPEO0014"
case compactBlockProcessorCacheDbMigrationFsCacheMigrationFailedSameURL
/// Deletion of readable file at the provided URL failed.
// sourcery: code="ZCBPEO0015"
case compactBlockProcessorCacheDbMigrationFailedToDeleteLegacyDb(_ error: Error)
/// Chain name does not match. Expected either 'test' or 'main'. This is probably an API or programming error.
// sourcery: code="ZCBPEO0016"
case compactBlockProcessorChainName(_ name: String)
/// Consensus BranchIDs don't match this is probably an API or programming error.
// sourcery: code="ZCBPEO0017"
case compactBlockProcessorConsensusBranchID
[#1140] ClearCache action before anything starts - draft [#1140] ClearCache action before anything starts - ClearCache action right after the idle action, clearing out metadata so the sync process can be fully restored from the DB and live blockchain values only. - InternalSyncProgress removed - InternalSyncProgressStorage removed - Sync process control logic updated, controlled by latestScannedHeight and firstUnenhancedHeight only - cleaned up unused code [#1140] ClearCache action before anything starts - ChecksBeforeSyncAction removed - Offline tests fixed [#1140] ClearCache action before anything starts - fixed injection of a wallet birthday, the sync range must start with wallet BD instead of lower bound [#1140] ClearCache action before anything starts - Network tests fixed - DarkSideTests partially fixed [#1140] ClearCache action before anything starts - rewind actions extension in compact block processor added [#1140] ClearCache action before anything starts - draft [#1140] ClearCache action before anything starts - DarkSideTests fixed [#1140] ClearCache action before anything starts - SyncRanges modified to be even less dependent on ranges, now it holds just 3 values (latest block height, latest scanned height if any, first unenhanced height if any), the rest is computed on the fly [#1140] ClearCache action before anything starts - SyncRanges struct not anymore, refactored to SyncControlData, holding just 3 mentioned values [#1140] ClearCache action before anything starts - cleanup [#1140] ClearCache action before anything starts (#1148) - TODO solved, the UTXOs fetcher doesn't work with range anymore, therefore reporting 100%
2023-06-20 02:59:56 -07:00
/// Rewind of DownloadBlockAction failed as no action is possible to unwrapp.
// sourcery: code="ZCBPEO0018"
case compactBlockProcessorDownloadBlockActionRewind
/// Put sapling subtree roots to the DB failed.
// sourcery: code="ZCBPEO0019"
case compactBlockProcessorPutSaplingSubtreeRoots(_ error: Error)
/// Getting the `lastScannedHeight` failed but it's supposed to always provide some value.
// sourcery: code="ZCBPEO0020"
case compactBlockProcessorLastScannedHeight
/// Getting the `supportedSyncAlgorithm` failed but it's supposed to always provide some value.
// sourcery: code="ZCBPEO0021"
case compactBlockProcessorSupportedSyncAlgorithm
2024-03-28 07:23:49 -07:00
/// Put Orchard subtree roots to the DB failed.
// sourcery: code="ZCBPEO0022"
case compactBlockProcessorPutOrchardSubtreeRoots(_ error: Error)
[#1140] ClearCache action before anything starts - draft [#1140] ClearCache action before anything starts - ClearCache action right after the idle action, clearing out metadata so the sync process can be fully restored from the DB and live blockchain values only. - InternalSyncProgress removed - InternalSyncProgressStorage removed - Sync process control logic updated, controlled by latestScannedHeight and firstUnenhancedHeight only - cleaned up unused code [#1140] ClearCache action before anything starts - ChecksBeforeSyncAction removed - Offline tests fixed [#1140] ClearCache action before anything starts - fixed injection of a wallet birthday, the sync range must start with wallet BD instead of lower bound [#1140] ClearCache action before anything starts - Network tests fixed - DarkSideTests partially fixed [#1140] ClearCache action before anything starts - rewind actions extension in compact block processor added [#1140] ClearCache action before anything starts - draft [#1140] ClearCache action before anything starts - DarkSideTests fixed [#1140] ClearCache action before anything starts - SyncRanges modified to be even less dependent on ranges, now it holds just 3 values (latest block height, latest scanned height if any, first unenhanced height if any), the rest is computed on the fly [#1140] ClearCache action before anything starts - SyncRanges struct not anymore, refactored to SyncControlData, holding just 3 mentioned values [#1140] ClearCache action before anything starts - cleanup [#1140] ClearCache action before anything starts (#1148) - TODO solved, the UTXOs fetcher doesn't work with range anymore, therefore reporting 100%
2023-06-20 02:59:56 -07:00
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
// MARK: - SDKSynchronizer
/// The synchronizer is unprepared.
// sourcery: code="ZSYNCO0001"
case synchronizerNotPrepared
/// Memos can't be sent to transparent addresses.
// sourcery: code="ZSYNCO0002"
case synchronizerSendMemoToTransparentAddress
/// There is not enough transparent funds to cover fee for the shielding.
// sourcery: code="ZSYNCO0003"
case synchronizerShieldFundsInsuficientTransparentFunds
/// LatestUTXOs for the address failed, invalid t-address.
// sourcery: code="ZSYNCO0004"
case synchronizerLatestUTXOsInvalidTAddress
/// Rewind failed, unknown archor height
// sourcery: code="ZSYNCO0005"
case synchronizerRewindUnknownArchorHeight
/// Indicates that this Synchronizer is disconnected from its lightwalletd server.
// sourcery: code="ZSYNCO0006"
case synchronizerDisconnected
/// The attempt to switch endpoints failed. Check that the hostname and port are correct, and are formatted as <hostname>:<port>.
// sourcery: code="ZSYNCO0007"
case synchronizerServerSwitch
/// The spending key does not belong to the wallet.
// sourcery: code="ZSYNCO0008"
case synchronizerSpendingKeyDoesNotBelongToTheWallet
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
}