I don't understand the value of separate endpoint. Why not have a middleware that catches exceptions discriminates by their types, builds the appropriate ProblemDetails and writes it to the response
There is no benefit in using the route approach like this. Normally you handle the exception using the IExceptionHandler interface and if you return false in the TryHandleError method, the route will receive the exception to further process (e.g. show a nice error html page). If you return true your exception is handled. I dont know any other reason why you want to use the route instead of the Interface in a plain API
@@Dustyy01 I agree aswell. If you want granular exception handling - IExceptionHandler is the way to go. However for easy/small services both approaches mentioned above are just fine.
Great content. One question. Is it best practice to throw exceptions in my code and catch them with global error handling? Or is it better to throw only exceptions that cannot be predicted?
I would choose IExceptionHandler over this approach for larger applications that need the modularity. For smaller apps, I personally prefer this approach
So if a client comes back with a traceid how would a developer find the real issue for that request? Are you saying we need to log it to db or something using the error endpoint?
Your videos are great, really appreciate it. I’m joining your discord
Thanks for the amazing demo Amichai Mantinband
I don't understand the value of separate endpoint. Why not have a middleware that catches exceptions discriminates by their types, builds the appropriate ProblemDetails and writes it to the response
Both are solid choices. It mostly comes down to preference
There is no benefit in using the route approach like this. Normally you handle the exception using the IExceptionHandler interface and if you return false in the TryHandleError method, the route will receive the exception to further process (e.g. show a nice error html page). If you return true your exception is handled.
I dont know any other reason why you want to use the route instead of the Interface in a plain API
@@Dustyy01 I agree aswell. If you want granular exception handling - IExceptionHandler is the way to go.
However for easy/small services both approaches mentioned above are just fine.
Great content. One question. Is it best practice to throw exceptions in my code and catch them with global error handling? Or is it better to throw only exceptions that cannot be predicted?
This is exactly next Monday’s video
perfect video 10/10
Great tutorial, but why not use a new IExceptionHandler abstraction for managing exceptions ?
I would choose IExceptionHandler over this approach for larger applications that need the modularity. For smaller apps, I personally prefer this approach
Good job. clean code as usual. i Hate you :D :D :D
Ty @amantinband
Great tutorial.
I would like to ask if the implementation is usable in a .net 8 MVC project?
Thank you @Amichai
Yep
@@amantinband Thank you
So if a client comes back with a traceid how would a developer find the real issue for that request? Are you saying we need to log it to db or something using the error endpoint?
What is the tool you used to highlight code? Or is it just done in post production
Presentify
any tips on how to do global error handling in Blazor? ErrorBoundary doesn't seem to catch everything
What icon plugin are you using in your VS Code?
vscode-icons
How can this be related to your ErrorOr ?
Can we use it also for grpc services?
why you don't respond to questions in the comments?
Not sure if this is 100% true or not ?! 🤔
I can’t always keep up with all the comments.. sorry if I missed your previous message 🙏🏼