Skip to content

Commit a024572

Browse files
committed
Move 'exception safety' section closer to the related exception guarantees section in Decoder/Encoder docs.
1 parent 99be485 commit a024572

File tree

2 files changed

+15
-13
lines changed

2 files changed

+15
-13
lines changed

core/commonMain/src/kotlinx/serialization/encoding/Decoding.kt

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -52,11 +52,17 @@ import kotlinx.serialization.modules.*
5252
* (`{` or `[`, depending on the descriptor kind), returning the [CompositeDecoder] that is aware of colon separator,
5353
* that should be read after each key-value pair, whilst [CompositeDecoder.endStructure] will parse a closing bracket.
5454
*
55-
* ### Exception guarantees.
56-
* For the regular exceptions, such as invalid input, missing control symbols or attributes and unknown symbols,
55+
* ### Exception guarantees
56+
*
57+
* For the regular exceptions, such as invalid input, missing control symbols or attributes, and unknown symbols,
5758
* [SerializationException] can be thrown by any decoder methods. It is recommended to declare a format-specific
5859
* subclass of [SerializationException] and throw it.
5960
*
61+
* ### Exception safety
62+
*
63+
* In general, catching [SerializationException] from any of `decode*` methods is not allowed and produces unspecified behavior.
64+
* After thrown exception, the current decoder is left in an arbitrary state, no longer suitable for further decoding.
65+
*
6066
* ### Format encapsulation
6167
*
6268
* For example, for the following deserializer:
@@ -79,11 +85,6 @@ import kotlinx.serialization.modules.*
7985
* }
8086
* ```
8187
*
82-
* ### Exception safety
83-
*
84-
* In general, catching [SerializationException] from any of `decode*` methods is not allowed and produces unspecified behaviour.
85-
* After thrown exception, current decoder is left in an arbitrary state, no longer suitable for further decoding.
86-
*
8788
* This deserializer does not know anything about the underlying data and will work with any properly-implemented decoder.
8889
* JSON, for example, parses an opening bracket `{` during the `beginStructure` call, checks that the next key
8990
* after this bracket is `stringValue` (using the descriptor), returns the value after the colon as string value

core/commonMain/src/kotlinx/serialization/encoding/Encoding.kt

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -51,11 +51,17 @@ import kotlinx.serialization.modules.*
5151
* (`{` or `[`, depending on the descriptor kind), returning the [CompositeEncoder] that is aware of colon separator,
5252
* that should be appended between each key-value pair, whilst [CompositeEncoder.endStructure] will write a closing bracket.
5353
*
54-
* ### Exception guarantees.
54+
* ### Exception guarantees
55+
*
5556
* For the regular exceptions, such as invalid input, conflicting serial names,
5657
* [SerializationException] can be thrown by any encoder methods.
5758
* It is recommended to declare a format-specific subclass of [SerializationException] and throw it.
5859
*
60+
* ### Exception safety
61+
*
62+
* In general, catching [SerializationException] from any of `encode*` methods is not allowed and produces unspecified behaviour.
63+
* After thrown exception, the current encoder is left in an arbitrary state, no longer suitable for further encoding.
64+
*
5965
* ### Format encapsulation
6066
*
6167
* For example, for the following serializer:
@@ -83,11 +89,6 @@ import kotlinx.serialization.modules.*
8389
* machinery could be completely different.
8490
* In any case, all these parsing details are encapsulated by an encoder.
8591
*
86-
* ### Exception safety
87-
*
88-
* In general, catching [SerializationException] from any of `encode*` methods is not allowed and produces unspecified behaviour.
89-
* After thrown exception, current encoder is left in an arbitrary state, no longer suitable for further encoding.
90-
*
9192
* ### Encoder implementation.
9293
*
9394
* While being strictly typed, an underlying format can transform actual types in the way it wants.

0 commit comments

Comments
 (0)