Comments (3)
I don't like the error wrapping approach because it will break all the existing tests and the error messages will be very ugly. The slice/multi-error approach will let use keep backwards compatibility. However, I'd like to understand the "why" a bit more. Can you describe a more specific use case?
maybe something like this?:
type UnsupportedError struct {
Raw string
Prefix string
}
func (e UnsupportedError) Error() string {
return fmt.Sprintf("nmea: invalid prefix: %s", e.Prefix)
}
type FieldError struct {
Context string
Value string
}
func (e FieldError) Error() string {
return fmt.Sprintf("nmea: invalid %s: %s", e.Context, e.Value)
}
type ParseError struct {
Raw string
Errors []error
}
func (e ParseError) Error() string {
if len(e.Errors) == 0 {
panic("nmea: empty error")
}
return e.Errors[0].Error()
}
from go-nmea.
when parsing fails it stops at first problem. which means that if there are more than 1 field problematic I would need to parse sentence multiple times to know what all problems are. In production environment this is impossible or tedious - especially if you are doing first assessment of the problem scope.
in certain situation when you use library just as a simple converter-gateway to another system (ala serial reader -> nmea parser -> mqtt -> ...) you want to delegate decision making from library to another component downstream. It is not possible to make decision if sentence that was parsed has incomplete values because parsing actually stopped after first error and relevant information for you is actually ok. For example - some enum fields can contain values that go-nmea does not recognize. I know from reading device manuals that sometimes manufacturers only document enum values that their device uses and left out values that are specified by NMEA. Sometimes values change - ala new GNSS constellations are launched. I think 15 year ago there were 4 constellations - now there are 6. Although gnss constellations are not enums, but there are cases where constellation is certain place at value for example GNS.Mode
field. Let alone obscure devices that send their custom values. I think there are already reported issues that there are devices that do not send CRC. Everything is easy when software is meant to use specific hardware - but situation where devices vary it gets harder as you can not predict what devices you are using in future.
Currently parsing methods return early when parser has already registered an error
func (p *Parser) Int64(i int, context string) int64 {
s := p.String(i, context)
if p.err != nil {
return 0
}
but maybe this could be made "optional" by some flag or default not to stop.
from go-nmea.
Ok, that makes sense to me. If you want to put together a PR I'll review. I don't think we need a flag to disable the short circuiting. We can just remove it without breaking anything.
from go-nmea.
Related Issues (20)
- The LonDir function seems to be incorrect. Longitude greater than 0 should be East, but this function returns West. HOT 1
- Fails to parse correct RMC sentence
- Fails to parse IIXDR HOT 4
- Make GPGLL struct fields JSON-serializable by adding corresponding tags HOT 3
- Latitude and Longitude in Decimal Format HOT 4
- Accept other talkers than "GP" HOT 14
- Replace testify with gotestools HOT 3
- Document message specification HOT 5
- sentence checksum error reported, though both values seem the same HOT 3
- nmea: sentence checksum mismatch [6B != 6B ] HOT 2
- Parse latitude and longitude along with the context of the direction HOT 2
- Support custom message types HOT 6
- Default value for empty string HOT 14
- DPT third field depends on nmea version? HOT 3
- feature: could sentence expose list of field names it has HOT 3
- MTK implementation is currently meant/suitable only for command PMTK001 but there are other messages/commands in MTK HOT 4
- latest version (v1.5.0) does not include the new supported sentences HOT 2
- possibility to make CRC check optional for certain sentences HOT 1
- processing multiline / segmented messages HOT 6
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 go-nmea.