@@ -69,7 +69,10 @@ func CopyFile(src, dst string) (err error) {
69
69
All of the listed above ** without any performance penalty** ! You are welcome to
70
70
run ` benchmarks ` in the project repo and see yourself.
71
71
72
- > [ !IMPORTANT]
72
+ <details >
73
+ <summary ><b >It's too fast!</b ></summary >
74
+ <br />
75
+
73
76
> Most of the benchmarks run 'too fast' according to the common Go
74
77
> benchmarking rules, i.e., compiler optimizations
75
78
> ([ inlining] ( https://en.wikipedia.org/wiki/Inline_expansion ) ) are working so
@@ -78,6 +81,8 @@ run `benchmarks` in the project repo and see yourself.
78
81
> The whole package is written toward that goal. Especially with parametric
79
82
> polymorphism, it's been quite the effort.
80
83
84
+ </details >
85
+
81
86
## Automatic Error Propagation
82
87
83
88
Automatic error propagation is crucial because it makes your * code change
@@ -218,7 +223,7 @@ error handlers where ever you want in your call stack. That can be handy in the
218
223
internal packages and certain types of algorithms.
219
224
220
225
<details>
221
- <summary>Immediate Error Handling Options</summary>
226
+ <summary><b> Immediate Error Handling Options</b> </summary>
222
227
<br/>
223
228
224
229
In cases where you want to handle the error immediately after the function call
@@ -305,7 +310,7 @@ development where you set pre- and post-conditions for *all* of your functions,
305
310
#### Asserters
306
311
307
312
<details>
308
- <summary>Fast Clean Code with Asserters</summary>
313
+ <summary><b> Fast Clean Code with Asserters</b> </summary>
309
314
<br/>
310
315
311
316
Asserts are not meant to replace the normal error checking but speed up the
@@ -365,7 +370,6 @@ boundaries.
365
370
<details>
366
371
<summary>The unit test code example:</summary>
367
372
368
-
369
373
` ` ` go
370
374
func TestWebOfTrustInfo (t *testing.T ) {
371
375
defer assert.PushTester (t)()
@@ -418,7 +422,7 @@ You can deploy your applications and services with the simple *end-user friendly
418
422
error messages and no stack traces.*
419
423
420
424
<details>
421
- <summary>You can switch them on when ever you need them again.</summary>
425
+ <summary>You can switch them on whenever you need them again.</summary>
422
426
<br/>
423
427
424
428
Let's say you have build CLI (` your-app` ) tool with the support for Go's flag
@@ -504,11 +508,12 @@ Flags:
504
508
## Code Snippets
505
509
506
510
<details>
507
- <summary>Most of the repetitive code blocks are offered as code snippets .</summary>
511
+ <summary>Code snippets as learning helpers .</summary>
508
512
<br/>
509
513
510
- They are in ` ./snippets` in VC code format, which is well supported e.g. neovim,
511
- etc.
514
+ The snippets are in ` ./snippets` and in VC code format, which is well supported
515
+ e.g. neovim, etc. They are proven to be useful tool especially when you are
516
+ starting to use the err2 and its sub-packages.
512
517
513
518
The snippets must be installed manually to your preferred IDE/editor. During the
514
519
installation you can modify the according your style or add new ones. We would
0 commit comments