Comments (6)
Related: #117
from bitshares-core.
From @theoreticalbts on July 6, 2015 4:3
Here is my proposal for an exception hierarchy:
graphene::chain::chain_exception
will be the root of anything that can happen in the chain DB.- Exception opcodes will be six digit numbers of the form
3xxyyzz
. - The initial digit
3
is inherited from the BTS 0.x exception numbering scheme. - The next two digits
xx
represent a phase of validation. - The meaning of the next four digits
yyzz
may depend onxx
. - For ops which represent operations,
xx
has the following meanings foryy
andzz
: yy
is the operation number (i.e. which member of thestatic_variant
inoperations.hpp
)zz
is the number of the exception within the operation
Compile-time template automagic will be used to enforce the correct value yy
(i.e. instead of hard-coding numbers, it will be done based on the compile-time-known static variant tag for the requrested type). Thus, reordering the operations will change exception codes!
Currently the following values of xx
are defined (in my private branch for this refactor):
xx = 01
: Database query exception. Thrown by methods which are raw queries to the chain database, e.g.get_recent_transaction()
.xx = 02
: Block validation exception. Thrown during evaluation of block-wide concerns (e.g. incorrect signing witness ID).xx = 03
: Transaction validation exception. Thrown during evaluation of tx-wide concerns (e.g. tx is expired).xx = 04
: Operation validation exception. Thrown by operation duringvalidate()
.xx = 05
: Operation evaluation exception. Thrown by some evaluator inevaluate()
.
from bitshares-core.
From @theoreticalbts on July 6, 2015 4:10
Note, many operations throw FC_ASSERT( fee_amount > 0 )
. My above-proposed scheme would assign different exception types / codes to each operation's version of this check.
This is actually a feature, not a flaw.
If the primary purpose of exceptions is to allow the testing framework to confirm that a specific assert exception triggers under the conditions set up by the test, then it makes sense to have each exception type thrown by a very small number of places in the code -- ideally in only one place. This makes each test able to confirm with high specificity that the observed exception does in fact indicate the desired assertion has failed, and not some other assertion.
from bitshares-core.
From @theoreticalbts on July 6, 2015 4:17
If it is desired to have a general insufficient_fee_exception
which is used for all fee_amount > 0
checks, it is possible to do so by making each op's exception for this condition descend from a base class insufficient_fee_exception
. This allows unit tests which test for specific ops to catch the fee_amount > 0
exception for that op, and then other code which wants to catch generic insufficient fee condition can catch the base class.
It seems hard to figure out an actual use case which would actually want to catch the base class, however -- which suggests this feature need not be implemented.
from bitshares-core.
From @theoreticalbts on August 17, 2015 17:12
Many commits progress, e.g. d4e4854 9c4ac2e 54103da 36e155b 35ab119 1b5a7cb
from bitshares-core.
Too complex
from bitshares-core.
Related Issues (20)
- Update pre-built binaries with the latest security updates from time to time
- Phase out Ubuntu 18.04 LTS (Bionic Beaver) HOT 1
- Draft Release Notes: BitShares Mekong 6.1.0 HOT 1
- ES `mapper_parsing_exception` error with `testnet-6.1.0` HOT 1
- ES `413 Request too large` error with `testnet-6.1.0` HOT 1
- Buyback orders that fail to place should not show in account history
- `operation_history_object::virtual_op` numbering may be discontinuous (possibly with holes)
- Missing account history data in ElasticSearch if node is restarted while syncing
- Support ElasticSearch version 8 HOT 1
- ElasticSearch plugins: HTTPS support
- Witness_node crashes on exit
- About Docker sunsetting Free Team organizations HOT 8
- Credit deal auto-renewal feature
- "sonar.cfamily.cache.enabled" and "sonar.cfamily.cache.path" properties are deprecated HOT 1
- Docker image issues
- Draft Release Notes: BitShares Core 7.0.0 "Suez" HOT 1
- `gethelp` command in CLI wallet built with Ubuntu 20 lacks docs for command parameters HOT 1
- Develop the functionality to create a list of accounts eligible to claim assets HOT 1
- Update get_ticker API to include liquidity pools
- Witness_node randomly stops syncing HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bitshares-core.