app/Config/OSPOS.php (1)

43-52: Narrow the exception catch to avoid masking non-database errors.

catch (\Exception $e) is sufficient and will still handle mysqli_sql_exception (which inherits from RuntimeException → Exception). Using \Throwable is unnecessarily broad and could silence TypeError or ValueError issues that indicate actual coding problems.

♻️ Proposed change

-            } catch (\Throwable $e) {
+            } catch (\Exception $e) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Config/OSPOS.php` around lines 43 - 52, The catch block currently uses
catch (\Throwable $e) which is too broad; change it to catch (\Exception $e) in
the same try/catch around the settings load so database-related errors
(including mysqli_sql_exception) are still handled but programmer errors like
TypeError/ValueError are not masked; keep the existing fallback assignment to
$this->settings ('language','language_code','company') and the existing comment
about migrations so behavior is unchanged except for narrowing the exception
type.

app/Libraries/MY_Migration.php (1)

46-49: Narrow these migration fallbacks to \Exception.

Returning 0/false on DB exceptions is appropriate for fresh installs, but catching \Throwable masks all errors, including unrelated PHP Errors and TypeErrors in the migration code itself. In PHP 8.1+, mysqli_sql_exception extends RuntimeException which extends Exception, so catch (\Exception $e) will still catch database exceptions while allowing programming errors to surface and fail the migration appropriately.

♻️ Proposed narrowing

-        } catch (\Throwable $e) {
+        } catch (\Exception $e) {
             // Database not available yet (e.g. fresh install before schema).
             // Catches mysqli_sql_exception which is not a DatabaseException.
             return 0;
@@
-        } catch (\Throwable $e) {
+        } catch (\Exception $e) {
             // Database not available yet (e.g. fresh install before schema).
             // Catches mysqli_sql_exception which is not a DatabaseException.
         }

Also applies to: 80-83

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Libraries/MY_Migration.php` around lines 46 - 49, The catch blocks in
MY_Migration that currently use catch(\Throwable $e) should be narrowed to
catch(\Exception $e) so programming Errors/TypeErrors are not swallowed; update
the two occurrences (the block returning 0/false for DB-not-ready fallbacks and
the other similar fallback around lines 80–83) to catch \Exception instead,
preserving the existing return 0/false behavior and logging if present so
database-related exceptions (like mysqli_sql_exception) are still handled but
actual PHP errors surface.

app/Config/Session.php (1)

141-147: Prefer catching \Exception to avoid masking unrelated PHP errors.

In PHP 8.2+, mysqli_sql_exception extends RuntimeException which extends Exception, so catch (\Exception $e) will still catch all database exceptions. However, catch (\Throwable $e) unnecessarily catches Error and its subclasses (such as TypeError, ParseError), which could hide legitimate PHP errors. Narrow the catch to \Exception to be explicit about what this code handles.

♻️ Proposed narrowing

-            } catch (\Throwable $e) {
+            } catch (\Exception $e) {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/Config/Session.php` around lines 141 - 147, The catch block in the
Session class currently catches \Throwable which can mask PHP Engine errors;
update the catch to catch \Exception instead so only exceptions are handled. In
the catch that assigns $this->driver = FileHandler::class and $this->savePath =
WRITEPATH . 'session' (inside the Session class initialization where the
DB-backed session setup occurs), replace catch (\Throwable $e) with catch
(\Exception $e) and keep the existing fallback logic unchanged.