Comments (9)
Hmm I guess worst-case this package could just have an implicit type for network errors. I'll probably worry more about error handling in a month or two to polish this stuff up
from rpc.
It's a little half-baked at the moment, I'm thinking a ./errors
pkg or similar (maybe still root) would be nice. Ideally all of the http status codes not just the few I special-cased here: https://github.com/apex/rpc/blob/master/error.go#L39-L56
But every error has to provide a human-friendly message and machine-friendly code so it ends up being say 400 { "type": "inavlid", "message": "The field 'title' is required" }
, but I need to think more about conventions, and add a way to document them in the schema :D
Maybe since everything is generated, you should list them in the schema and these stubs are created for you to use in your handlers.
from rpc.
I was wondering if unions could be used, so rather than having some kind of dedicated error handling we could say that a method (for example a get_user
method) returns union(UserObject, NotFoundError, UnauthenticatedError)
It could be generally useful for more complex methods too.
from rpc.
That could work, I'll give it some thought, in Go-land at least it would be more idiomatic to return error
(unfortunately haha). I guess it either ends up being awkward for some languages in either case, Go people would be like WUTTTT I have to switch on a type??. I'll rename this so we can try to figure out if that would work
from rpc.
I would have thought an error from the library would be that the transport failed, rather than it being a business logic error. It is tricky to draw the lines though.
One thing about using Go's error mechanism for all error cases is that it's no longer possible to return multiple errors, so people using this to drive a UI wouldn't be able to show all the validation problems to the user without rolling their own secondary error handling.
from rpc.
True true, I did want to support arbitrary error context, just some object or whatever you want along-side type
and message
, but there's no reason that errors need to be standard across projects really. I'm definitely down with unions, but then we need a solution for languages that don't support unions — or don't support them well
from rpc.
In Go would having an interface with the members documented be sufficient? I'm not sure how common it is to downcast from an interface
from rpc.
It's totally doable in Go, but definitely not idiomatic, you pretty much never see a single interface value returned which acts as a union for errors as well. Maybe that will change once generics are introduced, but returning (value, error)
is so wide-spread.
Maybe we can still treat errors in the schema as regular types, but have methods provide errors: [variants, here]
so they're still separated from any result type. It's not quite as elegant, but languages with unions we could combine the result and error types, and for cases like Go it's still easy to separate them. Something like that haha.
from rpc.
A success union and an error union could map well onto Go, languages with exceptions, and languages with a Result type. :)
Would network errors get automatically merged into the error union?
from rpc.
Related Issues (20)
- Add the schema's version to the output
- Target all JavaScript platforms with one generator HOT 5
- Move rpc-apex-docs
- Generate Terraform providers
- Improved validation error messages
- Generate CLIs
- timestamp fields get parsed as string in the ts client HOT 13
- Mock server for testing
- Generate Go example for docs
- [TS client] string fields containing timestamps get parsed as Date objects
- Add "since" schema property for the version introducing a type/method
- Swift client
- Gleam client
- Dotnet client
- Elixir client
- Clojure client HOT 1
- Scala client
- Crystal client
- [TS types] can we have camel casing for field names? 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 rpc.