Nano-node: Should we go for exceptions?

Created on 8 Jan 2018  路  13Comments  路  Source: nanocurrency/nano-node

The topic of exceptions came up in https://github.com/clemahieu/raiblocks/pull/439

There's a lot of code in the source tree that does error handling by checking return codes.

I don't necessarily think throwing exceptions everywhere is appropriate, but some of the code would certainly benefit from a well designed exception hierarchy/structure. And a lot of boost/std methods throw exceptions anyway.

question

Most helpful comment

I think node_init is a good example. Any error triggered with it is fatal at run-time and currently the context of the error is lost to a success/fail flag. The result is the user only sees a "error initializing node" output with little else to go off of.

All 13 comments

unless the failure result is not discardable, there's no point of exceptions. for example, in the read_header method, does it matter if the magic number doesn't match or the version is wrong? I think that would only matter for analyzing debug logs, but without the payload itself, would be of no use. I guess the short-circuiting is the way to go

With exceptions though, you don't have to do short circuiting. You can just call the functions and only worry about failure where it needs handled.

@pocesar I don't think the read_header method is a good example for the exception discussion. There's a lot more complex methods (and chains thereof) that would benefit more.

I'm not fond of exceptions for code that are executed in tight loops, that's something to be aware of. even if it's better for code maintainability, exceptions shouldn't be thrown in functions that performance is crucial (read_header is one of them)

C++ exceptions are only slow for the failure case though. How crucial is performance then? I don't think it'll be the bottleneck.

@PlasmaPower Right. I think the summary at the end of https://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/ is good (at least for Itanium ABI compilers).

In short, it probably doesn't matter, especially not in code dominated by IO where exception cost is basically noise. The "happy path" is fast, but the concern is definitely something to consider in critical paths.

if you think that the nodes / clients will always receive sane packets, indeed, exceptions will be rare. that's not the case

No, I just think that the vast majority (but not 100%) of packets will be sane. I'm also confident this is not the weakest link for a DDOS attack.

In this particular instance it's a dumb waste of cpu cycles in code where the benefit is zero, minus the time that could have been spent programming something useful.

@lukealonso yeah, there are much better candidates than read_header for exception treatment. Although the shortcutting idiom isn't a beauty, it's sometimes a nice middle ground.

I think node_init is a good example. Any error triggered with it is fatal at run-time and currently the context of the error is lost to a success/fail flag. The result is the user only sees a "error initializing node" output with little else to go off of.

@Dekoze right, I had the same problem in the daemon, which I've addressed in https://github.com/clemahieu/raiblocks/pull/480

Going for std::error_code / std::expect instead.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

paulmelis picture paulmelis  路  6Comments

androm3da picture androm3da  路  3Comments

i3bitcoin picture i3bitcoin  路  4Comments

fallerOfFalls picture fallerOfFalls  路  4Comments

FndNur1Labs picture FndNur1Labs  路  6Comments