📝 Tweak docs about re-raising validation errors

docs/en/docs/tutorial/handling-errors.md

@@ -127,7 +127,7 @@ To override it, import the `RequestValidationError` and use it with `@app.except
 
 The exception handler will receive a `Request` and the exception.
 
-{* ../../docs_src/handling_errors/tutorial004.py hl[2,14:16] *}
+{* ../../docs_src/handling_errors/tutorial004.py hl[2,14:19] *}
 
 Now, if you go to `/items/foo`, instead of getting the default JSON error with:
 
@@ -149,36 +149,17 @@ Now, if you go to `/items/foo`, instead of getting the default JSON error with:
 you will get a text version, with:
 
 ```
-1 validation error
-path -> item_id
-  value is not a valid integer (type=type_error.integer)
+Validation errors:
+Field: ('path', 'item_id'), Error: Input should be a valid integer, unable to parse string as an integer
 ```
 
-#### `RequestValidationError` vs `ValidationError` { #requestvalidationerror-vs-validationerror }
-
-/// warning
-
-These are technical details that you might skip if it's not important for you now.
-
-///
-
-`RequestValidationError` is a sub-class of Pydantic's <a href="https://docs.pydantic.dev/latest/concepts/models/#error-handling" class="external-link" target="_blank">`ValidationError`</a>.
-
-**FastAPI** uses it so that, if you use a Pydantic model in `response_model`, and your data has an error, you will see the error in your log.
-
-But the client/user will not see it. Instead, the client will receive an "Internal Server Error" with an HTTP status code `500`.
-
-It should be this way because if you have a Pydantic `ValidationError` in your *response* or anywhere in your code (not in the client's *request*), it's actually a bug in your code.
-
-And while you fix it, your clients/users shouldn't have access to internal information about the error, as that could expose a security vulnerability.
-
 ### Override the `HTTPException` error handler { #override-the-httpexception-error-handler }
 
 The same way, you can override the `HTTPException` handler.
 
 For example, you could want to return a plain text response instead of JSON for these errors:
 
-{* ../../docs_src/handling_errors/tutorial004.py hl[3:4,9:11,22] *}
+{* ../../docs_src/handling_errors/tutorial004.py hl[3:4,9:11,25] *}
 
 /// note | Technical Details
 
@@ -188,6 +169,14 @@ You could also use `from starlette.responses import PlainTextResponse`.
 
 ///
 
+/// warning
+
+Have in mind that the `RequestValidationError` contains the information of the file name and line where the validation error happens so that you can show it in your logs with the relevant information if you want to.
+
+But that means that if you just convert it to a string and return that information directly, you could be leaking a bit of information about your system, that's why here the code extracts and shows each error independently.
+
+///
+
 ### Use the `RequestValidationError` body { #use-the-requestvalidationerror-body }
 
 The `RequestValidationError` contains the `body` it received with invalid data.