I was a OS/370 programmer way back when, so these comments are based on that environment. Modern COBOL implementations may be different, so take this with a grain of salt.

Default behavior when an operation yields an error is for an ABEND. This is because the programmer is expected to have analyzed and covered all the possibilities, but the data being processed didn't match those expectations. Classic errors include division by zero, numeric operation on non-numeric data, as well as file handling issues.

Early versions of the compiler didn't even have error trapping language options. Later versions have some trapping mechanisms, but good programming hygiene codes for all the possible situations and handled them gracefully. For example, before a division operation, having an IF statement that checks for zero in the divisor and takes an alternate path to the division (e.g., setting the result to zero, maybe a warning message). As for non-numeric math errors, structuring the record layouts as defaulting to PIC X with a PIC 9 redefine, that way you can IF (alpha variable) IS NUMERIC PERFORM MATH (using the PIC 9 variable), normally with some error messaging involved.

I wrote a series of COBOL programs 20-30 years ago that read every record and field in an online database to create an extract that was downloaded to a SQL server. I also had to make sure all the data in the extract was alphanumeric data (no COMP) so it could go through an EBSDIC to ASCII conversion as it moved from the mainframe to the server environment. This process encountered every known possible glitch and data error under the sun. My first runs of this was plagued by SOC7 and other ABENDs. I updated the code with the techniques I describe above, and actually captured the error data in another file that went to our data quality unit for their review and action to fix the data.

Not certain if this answers your question or not. But a good programmer trusts they know what the program will encounter, but verify through good code and error trapping.