API Error Messages for a GOOD Developer Experience

  Рет қаралды 9,163

CodeOpinion

CodeOpinion

Күн бұрын

Пікірлер: 36
@CodeOpinion
@CodeOpinion 4 ай бұрын
And boom goes the dynamite 💥... if you go that reference!
@kis.stupid
@kis.stupid 4 ай бұрын
But I guess it makes more sense to design the behaviors in the back-end if you need to serve multiple front-ends implementing the exact same behaviors.
@jackeinstein2184
@jackeinstein2184 4 ай бұрын
I dislike all these tutorials (often created by amateurs) that simply tell people, 'Don't do this, don't do that,' without discussing the advantages and disadvantages of each approach. In reality, whether it involves using exception or returning error approach, both methods can be appropriate. Each has its benefits and drawbacks, and the best choice depends on the specific context.
@CodeOpinion
@CodeOpinion 4 ай бұрын
Context is King👑
@sanglin9387
@sanglin9387 4 ай бұрын
You can use try catch no problem on that . For me , just return array or false status only as we use ajax respond. The smaller is much better . Do remind , always log your error upon catch error . If you don't have error handling , it kinda hard to debug for long term . We do tutorial but not in this nick name. The best trend not return try catch error like old days but still we need a backup if something happen.
@michaldivismusic
@michaldivismusic 4 ай бұрын
One of the things that's bugging me with throwing exceptions for things like not found or validation errors is that you'll see those in your logs as errors when in reality they're not really errors in my mind. You'll then see an error level message in your logs whenever a user submits a request with a missing field and at the same time the other error messages can be actual errors like the connection to a database timed out. But trying to convince everyone else at work to abandon using exceptions to control flow is damn near impossible.
@bernhardkrickl5197
@bernhardkrickl5197 4 ай бұрын
Yeah, but it's important. There's this great book called "Effective Java". It has a chapter about exceptions which, among other things, speaks about this problem. I don't know if you use Java, but I guess most of the principle about exceptions apply in other languages as well.
@Unleash132
@Unleash132 4 ай бұрын
Option is not really a good replacement for exceptions because you might have different types of errors you want to "return" to the caller. I think the Result monad is better here since it usually carries an error List which can then be translated to api errors.
@CodeOpinion
@CodeOpinion 4 ай бұрын
Agree, assuming you have more than just one outcome.
@gardnerjens
@gardnerjens 4 ай бұрын
for basic lookup on an entity i think Option is great, but agreed if something else fails then Result is better. Though i think result quickly turns into a hammer, and everything must be a result. At that point you loose your clarity of return types.
@sodreigor
@sodreigor 4 ай бұрын
How do you deal with the Option type across multiple DLLs? Do you define them in every project? Do use a "shared" folder with Util methods/types in it? How about when you have an internal nugget package that has it? Kinda of a bummer that C# still has not added Union types yet.
@CodeOpinion
@CodeOpinion 4 ай бұрын
Any of the above. Agree, I wish there was not only something built in but also as a c# feature that was easer to use. It can often be a bit clunky.
@adambickford8720
@adambickford8720 4 ай бұрын
Its not that simple as it adds maintenance. Now you have to make sure that your 'advice' is true. For example, they could remove that coupling but now you have to remember to update the verbiage. In practice error messages are opaque strings you throw into some kind of search engine/ai
@CodeOpinion
@CodeOpinion 4 ай бұрын
In majority of practice, they are for sure. It absolutely can be a maintenance burden on you. But like many things, it's what you value. Do you want the burden of maintaining correct and accurate errors, or do you want to put the burden on your consumers to decipher the error to find a solution? As always, depends on your context. It reminds me of the idea of versioning your HTTP API and Roy Fielding saying "a v1 is a middle finger to your API customers".
@Cesar-qi2jb
@Cesar-qi2jb 4 ай бұрын
We prefer handling our own application exceptions in a global exception handler. Much esier and it doesn't affect performance in our regular successful calls.
@bernhardkrickl5197
@bernhardkrickl5197 4 ай бұрын
Just make sure you raise exceptions only for exceptional, i.e. unexpected (unexpectable?) problems. Not finding an order by some ID is not exceptional, since the "findOrderByID" method has no control over the ID passed in. The caller must handle this case eg. by giving the user some sensible feedback or trying/suggesting an alternative. A simple "catch all" block in some central place will not do that. However, it is a good strategy for catching everything that was not caught elsewhere.
@Cesar-qi2jb
@Cesar-qi2jb 4 ай бұрын
@@bernhardkrickl5197 we define our custom exceptions in the Application layer
@PatricSjoeoe
@PatricSjoeoe 4 ай бұрын
What Option library do you use?
@CodeOpinion
@CodeOpinion 4 ай бұрын
It's easy enough to create your own.
@semosancus5506
@semosancus5506 4 ай бұрын
I like to do this too. I implemented a pretty robust error mechanism for REST APIs, but then the security team and product management colluded and told me I have to make more generic errors because I'm giving away attack vectors and its all too complex for the user. 🤷
@13odman
@13odman 4 ай бұрын
Yeah, the errors returned from the api and the errors thrown are two different things. He’s talking about the code level
@CodeOpinion
@CodeOpinion 4 ай бұрын
I want to reduce the number of support requests for whoever the intended message is for.
@georgehelyar
@georgehelyar 4 ай бұрын
Could still just be a bad security team. I've had so called security people tell me to hide things in the name of security before because they don't understand that obscurity is not security e.g. you should make the API require authorization, not try to hide something like an order id. I ended up base 64 encoding it to shut them up and they were dumb enough to think that helped, but sometimes it's just politics.
@7th_CAV_Trooper
@7th_CAV_Trooper 4 ай бұрын
You can record the real errors in your log and return more generic msg from your rest API. Use a middleware for this so you can change behavior for prod and integration environments.
@sanglin9387
@sanglin9387 4 ай бұрын
generic mean like owasp but you still need return a log to understand for admin if anything happen wrong.
@swarupmahapatra1
@swarupmahapatra1 4 ай бұрын
If there is a chain of function call A -> B -> C -> D, and each function returns a Result type, then every function needs to do an "if-else" check . This according to me is a bit too much. I prefer exceptions, so that the code reads very declarative . The exceptions needs to be caught at the edge of the systems (like the API controllers).
@bernhardkrickl5197
@bernhardkrickl5197 4 ай бұрын
Exceptions are for exceptional cases. Not finding some stuff by an ID is not exceptional.
@7th_CAV_Trooper
@7th_CAV_Trooper 4 ай бұрын
throw new Ex("programme's note to self: Oops") Thumbs up for use of Option
@SimonLiSeeking
@SimonLiSeeking 4 ай бұрын
Its pity option is not builtin, instead, ? is recommended.
@Stoney_Eagle
@Stoney_Eagle 4 ай бұрын
I have to use an API that may omit a whole relation block when it doesn't feel like giving it and have to retry max 10 times to make sure it actually doesn't exist. That's worse than bad error messages 😅
@morrisonbrett
@morrisonbrett 4 ай бұрын
Fellow hockey player here. Love that you play hockey. Flip your video in editing so it's not reversed lettering! Thanks for all your great content. Very helpful!
@CodeOpinion
@CodeOpinion 4 ай бұрын
First person to notice! Just how my setup is at the moment. I plan on switching it around so its not reserved soon enough.
You're not as loosely coupled as you think!
8:03
CodeOpinion
Рет қаралды 6 М.
My WORST Mistakes as a Software Developer
7:52
CodeOpinion
Рет қаралды 10 М.
Крутой фокус + секрет! #shorts
00:10
Роман Magic
Рет қаралды 20 МЛН
How To Get Married:   #short
00:22
Jin and Hattie
Рет қаралды 21 МЛН
Want to build a good API? Here's 5 Tips for API Design.
10:57
CodeOpinion
Рет қаралды 206 М.
JavaScript Error Handling: 5 Things You Aren’t Thinking About!
14:42
If Your Code Looks Like This... You're A GOOD Programmer
16:39
Continuous Delivery
Рет қаралды 71 М.
Laravel vs Rails for Javascript developers
19:50
Sam Lewis
Рет қаралды 2,5 М.
Exceptions are evil. This is what I do instead.
24:41
Amichai Mantinband
Рет қаралды 20 М.
Being Competent With Coding Is More Fun
11:13
TheVimeagen
Рет қаралды 81 М.
HTMX: What's Old is New Again
11:18
CodeOpinion
Рет қаралды 16 М.
Feature Flags are more than just Toggles
9:12
CodeOpinion
Рет қаралды 12 М.
Keep your project structure simple!
15:08
CodeOpinion
Рет қаралды 18 М.
"Serverless sucks!"... or does it?
7:27
CodeOpinion
Рет қаралды 7 М.
Крутой фокус + секрет! #shorts
00:10
Роман Magic
Рет қаралды 20 МЛН