From 884b0132c75f6cb4acc306ef9ae41d10b3dde6f8 Mon Sep 17 00:00:00 2001 From: Marcelo Soares Date: Thu, 8 Jan 2026 00:54:38 -0300 Subject: [PATCH] docs: Add a reference of where uncaught exceptions are logged --- docs/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-1.1.0/04-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-1.1.1/05-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-1.2.0/05-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.0.0/05-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.1.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.2.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.3.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.4.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.5.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.6.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.7.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.8.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-2.9.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-3.0.0/06-concepts/04-exceptions.md | 6 ++++-- versioned_docs/version-3.1.0/06-concepts/04-exceptions.md | 6 ++++-- 16 files changed, 64 insertions(+), 32 deletions(-) diff --git a/docs/06-concepts/04-exceptions.md b/docs/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/docs/06-concepts/04-exceptions.md +++ b/docs/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md b/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md index b6e0db7d..dd0e0651 100644 --- a/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md +++ b/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md @@ -1,12 +1,14 @@ # Error handling and exceptions Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md b/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md index b6e0db7d..dd0e0651 100644 --- a/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md +++ b/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md @@ -1,12 +1,14 @@ # Error handling and exceptions Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md b/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md index a74c880a..b52941d8 100644 --- a/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md +++ b/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md @@ -1,12 +1,14 @@ # Error handling and exceptions Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md b/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md index 21152af4..7284f6d3 100644 --- a/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md +++ b/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.3.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.3.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.3.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.3.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.4.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.4.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.4.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.4.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.5.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.5.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.5.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.5.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.6.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.6.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.6.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.6.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.7.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.7.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.7.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.7.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.8.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.8.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.8.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.8.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-2.9.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.9.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-2.9.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-2.9.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-3.0.0/06-concepts/04-exceptions.md b/versioned_docs/version-3.0.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-3.0.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-3.0.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions diff --git a/versioned_docs/version-3.1.0/06-concepts/04-exceptions.md b/versioned_docs/version-3.1.0/06-concepts/04-exceptions.md index e4baa660..f84e8379 100644 --- a/versioned_docs/version-3.1.0/06-concepts/04-exceptions.md +++ b/versioned_docs/version-3.1.0/06-concepts/04-exceptions.md @@ -2,12 +2,14 @@ Handling errors well is essential when you are building your server. To simplify things, Serverpod allows you to throw an exception on the server, serialize it, and catch it in your client app. -If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identifiy the call in your logs. +If you throw a normal exception that isn't caught by your code, it will be treated as an internal server error. The exception will be logged together with its stack trace, and a 500 HTTP status (internal server error) will be sent to the client. On the client side, this will throw a non-specific ServerpodException, which provides no more data than a session id number which can help identify the call in your logs. :::tip - Use the Serverpod Insights app to view your logs. It will show any failed or slow calls and will make it easy to pinpoint any errors in your server. +::: +:::info +Uncaught exceptions thrown in endpoints are logged in the `serverpod_session_log` table, not in the `serverpod_log` table. To understand more about the differences between these two tables, you can read more about [logging](logging) in Serverpod. ::: ## Serializable exceptions