Updates to error handling #468

mattldawson · 2024-04-20T01:05:00Z

Adds custom error codes to MICM classes and updates existing error handling to use them. The hope is that in the MUSICA library we can catch these errors and turn them into meaningful codes/messages that can be returned through the C API.

closes #466

codecov-commenter · 2024-04-20T14:00:16Z

Codecov Report

Attention: Patch coverage is 64.89362% with 99 lines in your changes are missing coverage. Please review.

Project coverage is 93.02%. Comparing base (20da447) to head (e214cbe).
Report is 2 commits behind head on main.

Files	Patch %	Lines
include/micm/configure/solver_config.hpp	83.33%	22 Missing ⚠️
include/micm/process/process_set.hpp	0.00%	13 Missing ⚠️
include/micm/jit/jit_compiler.hpp	0.00%	12 Missing ⚠️
include/micm/process/rate_constant.hpp	0.00%	12 Missing ⚠️
include/micm/solver/rosenbrock.inl	0.00%	12 Missing ⚠️
include/micm/solver/state.inl	70.37%	8 Missing ⚠️
include/micm/process/process.hpp	63.63%	4 Missing ⚠️
include/micm/util/matrix_error.hpp	77.77%	4 Missing ⚠️
include/micm/solver/jit_rosenbrock.hpp	0.00%	3 Missing ⚠️
include/micm/system/species.hpp	85.00%	3 Missing ⚠️
... and 4 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #468      +/-   ##
==========================================
- Coverage   94.34%   93.02%   -1.33%     
==========================================
  Files          39       40       +1     
  Lines        3166     3167       +1     
==========================================
- Hits         2987     2946      -41     
- Misses        179      221      +42

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

K20shores

I like it! I guess one concern is that we are potentially masking system errors in our tests if they were ever to be thrown and happen to have the same numerical value as the micm error values.

And on that note, in MUSICA, I don't see how we will be able to identify exactly which error was thrown since we have overlapping codes. It seems like we would need to know exactly which part of the code threw this so that we know which enum class to match the error code to. What am I missing?

mattldawson · 2024-04-22T15:36:46Z

I like it! I guess one concern is that we are potentially masking system errors in our tests if they were ever to be thrown and happen to have the same numerical value as the micm error values.

And on that note, in MUSICA, I don't see how we will be able to identify exactly which error was thrown since we have overlapping codes. It seems like we would need to know exactly which part of the code threw this so that we know which enum class to match the error code to. What am I missing?

Yeah, I was starting to work through that in the MUSICA library. One option might be to use a combination of the category name and the int value of the enum. Something like:

struct Error {
  int code_;
  const char* category_;
  const char* message_;
};

With this to turn std::system_error into an Error:

Error ToError(const std::system_error& e)
{
    Error error;
    error.code_ = e.code().value();
    error.category_ = e.code().category().name();
    error.message_ = e.what();
    return error;
}

This way on the user side (even in Fortran, and I'm guessing Python), you could use strcmp(error.category_, "MICM Matrix") == 0 && error.code_ == 2 to identify our MicmMatrixErrc::InvalidVector error. And this should avoid us masking other system errors. What do you think?

WardF · 2024-04-22T16:14:43Z

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

K20shores · 2024-04-22T16:59:36Z

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

sjsprecious · 2024-04-22T17:12:30Z

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

mwaxmonsky · 2024-04-22T17:19:57Z

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

If we do, we might be able to leverage the C++ library: https://en.cppreference.com/w/cpp/utility/source_location

mattldawson · 2024-04-22T17:26:50Z

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

WardF

The functionality of this looks good, albeit I'm taking a 10,000 foot view. My one thought is that the code would benefit from some comments; while a lot of it is self evident now, it might be less so down the road. "Code needing more in-line comments" is hardly novel feedback, I acknowledge XD. Particularly since it could apply to any number of my own PRs. But since I'm looking at this as an outsider and not a core developer, the function is less immediately obvious to me, and the lack of comments stands out more.

mattldawson · 2024-04-22T17:29:38Z

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

I like that too. The only thing that's a little unclear to me is how the dependencies would work. If the error codes live in MUSICA, would MICM and TUV-x depend on MUSICA? Or if they live in MICM and TUV-x, would MICM and TUV-x depend on each other?

WardF · 2024-04-22T17:32:07Z

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

I like that too. The only thing that's a little unclear to me is how the dependencies would work. If the error codes live in MUSICA, would MICM and TUV-x depend on MUSICA? Or if they live in MICM and TUV-x, would MICM and TUV-x depend on each other?

If each project maintained a list of errors, their own errors.h, or <project>_errors.h which could be included as part of error handling, would that avoid explicit dependencies between the projects for error handling? I feel like that's a naive question, but it's the first that springs to mind.

WardF · 2024-04-22T17:36:01Z

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

From experience, ASSERT is great when it works for the intended purpose, but when it leaks out into user-space (e.g. unexpected/unanticipated behavior results in an 'unreachable' ASSERT being reached by a user at runtime) it can become a bit of a pain. So I guess with careful planning, using an ASSERT for debugging purposes instead of FILE and LINE would work. +100 to the idea of 'clear error messaging'.

From a user support perspective, I wonder now about a user sending you details around a problem they had. Would the error be enough for you to debug what's going on? Or would __FILE__ and __LINE__ be useful information to you then? Just thinking out loud, clearly.

mattldawson · 2024-04-22T17:41:28Z

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

I like that too. The only thing that's a little unclear to me is how the dependencies would work. If the error codes live in MUSICA, would MICM and TUV-x depend on MUSICA? Or if they live in MICM and TUV-x, would MICM and TUV-x depend on each other?

If each project maintained a list of errors, their own errors.h, or <project>_errors.h which could be included as part of error handling, would that avoid explicit dependencies between the projects for error handling? I feel like that's a naive question, but it's the first that springs to mind.

I like that idea. Would you expect the error header to just define the int codes and the category strings? Something like:

#define ERR_CAT_MICM_MATRIX "MICM Matrix"
#define ERR_CODE_MICM_ROW_SIZE_MISMATCH 1
#define ERR_CODE_MICM_INVALID_VECTOR 2

and then update, e.g., the Matrix class to use them:

enum class MicmMatrixErrc
{
  RowSizeMismatch = ERR_CODE_MICM_ROW_SIZE_MISMATCH,
  InvalidVector = ERR_CODE_MICM_INVALID_VECTOR,
};

namespace
{
  class MicmMatrixErrorCategory : public std::error_category
  {
   public:
    const char *name() const noexcept override
    {
      return ERR_CAT_MICM_MATRIX;
    }
    ...

The only thing might be that we couldn't use the same label for specific errors in different categories. (like if INVALID_VECTOR is an error in another class like SparseMatrix)

mattldawson · 2024-04-22T17:51:12Z

The functionality of this looks good, albeit I'm taking a 10,000 foot view. My one thought is that the code would benefit from some comments; while a lot of it is self evident now, it might be less so down the road. "Code needing more in-line comments" is hardly novel feedback, I acknowledge XD. Particularly since it could apply to any number of my own PRs. But since I'm looking at this as an outsider and not a core developer, the function is less immediately obvious to me, and the lack of comments stands out more.

I have gone back and forth over time between 'comment everything' and 'try to write self-documenting code', and I don't know where I'm at right now. I'm happy to add more comments though. Was there anything in particular that you noticed should have more documentation?

mattldawson · 2024-04-22T17:54:23Z

Another benefit to the single file for errors might be that if we just use CPP definitions, we can include the same header in the fortran wrapper code and maybe cut down on the passing back and forth of strings between c and fortran or keeping this list in two places.

mattldawson · 2024-04-22T18:12:00Z

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

From experience, ASSERT is great when it works for the intended purpose, but when it leaks out into user-space (e.g. unexpected/unanticipated behavior results in an 'unreachable' ASSERT being reached by a user at runtime) it can become a bit of a pain. So I guess with careful planning, using an ASSERT for debugging purposes instead of FILE and LINE would work. +100 to the idea of 'clear error messaging'.

From a user support perspective, I wonder now about a user sending you details around a problem they had. Would the error be enough for you to debug what's going on? Or would __FILE__ and __LINE__ be useful information to you then? Just thinking out loud, clearly.

In going through the process of making these changes, I think it would be pretty clear what part of the code threw the error (the error categories are specific to one class, or in one case two classes that extend the same base class, and the individual errors are mostly only thrown in one place, or a few places at most).

To me what's important is that these errors always indicate a problem that the user should address, not one that indicates a bug in our code. If we also want to make it easier for users to report bugs in our code, what if we added something like an InternalMicmErrc? If we add some run-time bug check to our code that trips, it could throw this and include the file and line number of the detailed message. The user would get something like "Internal MICM Error(file, line): Please file a bug report..." What does everyone think of something like this?

sjsprecious · 2024-04-22T18:29:57Z

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

From experience, ASSERT is great when it works for the intended purpose, but when it leaks out into user-space (e.g. unexpected/unanticipated behavior results in an 'unreachable' ASSERT being reached by a user at runtime) it can become a bit of a pain. So I guess with careful planning, using an ASSERT for debugging purposes instead of FILE and LINE would work. +100 to the idea of 'clear error messaging'.
From a user support perspective, I wonder now about a user sending you details around a problem they had. Would the error be enough for you to debug what's going on? Or would __FILE__ and __LINE__ be useful information to you then? Just thinking out loud, clearly.

In going through the process of making these changes, I think it would be pretty clear what part of the code threw the error (the error categories are specific to one class, or in one case two classes that extend the same base class, and the individual errors are mostly only thrown in one place, or a few places at most).

To me what's important is that these errors always indicate a problem that the user should address, not one that indicates a bug in our code. If we also want to make it easier for users to report bugs in our code, what if we added something like an InternalMicmErrc? If we add some run-time bug check to our code that trips, it could throw this and include the file and line number of the detailed message. The user would get something like "Internal MICM Error(file, line): Please file a bug report..." What does everyone think of something like this?

Ah, I see. I am thinking about the code bug and I want the error message to be direct and pointed to the specific source code for faster debugging later. But regarding a user error, what you and others propose here makes sense to me, and using an error header file with enumed error code sounds a good idea. Thanks for your clarification.

boulderdaze · 2024-04-22T18:33:13Z

I like it! I guess one concern is that we are potentially masking system errors in our tests if they were ever to be thrown and happen to have the same numerical value as the micm error values.
And on that note, in MUSICA, I don't see how we will be able to identify exactly which error was thrown since we have overlapping codes. It seems like we would need to know exactly which part of the code threw this so that we know which enum class to match the error code to. What am I missing?

Yeah, I was starting to work through that in the MUSICA library. One option might be to use a combination of the category name and the int value of the enum. Something like:
struct Error {
  int code_;
  const char* category_;
  const char* message_;
};
With this to turn std::system_error into an Error:
Error ToError(const std::system_error& e)
{
    Error error;
    error.code_ = e.code().value();
    error.category_ = e.code().category().name();
    error.message_ = e.what();
    return error;
}
This way on the user side (even in Fortran, and I'm guessing Python), you could use strcmp(error.category_, "MICM Matrix") == 0 && error.code_ == 2 to identify our MicmMatrixErrc::InvalidVector error. And this should avoid us masking other system errors. What do you think?

I like this idea

boulderdaze

Looks good! Many interesting discussions above. I am not very familiar with the system_error header but we might be able to create a macro to avoid having to create each error category class to the applicable classes? something like,
MICM_ERROR(category, error code, message)
Just a thought, thanks for the work! I think it's quite tricky to design the error handler since we also have to consider MUSICA.

mattldawson · 2024-04-22T21:29:40Z

Based on the discussion, I'll go ahead and create a micm error header and add an internal error category that includes the filename and line number in the message. (I'm not sure if we actually have any run-time checks that I can apply this to, but if I can't find one I'll just add a test that throws this error.)

I'll request a re-review once that's ready, but let me know if you would prefer not to review this again and I won't include you in the re-review.

Thanks for the discussion everyone!

K20shores · 2024-04-23T14:07:34Z

include/micm/configure/solver_config.hpp

-namespace micm
+enum class MicmConfigErrc
+{
+  Success = MICM_CONFIGURATION_ERROR_CODE_SUCCESS,


Now that we have a better error system, should we think about removing the success status since it's not an error? Rather than checking the return value throughout the configuration, we can throw an error when we arrive at one

Good point. I'll do that now.

K20shores · 2024-04-23T14:12:49Z

include/micm/util/error.hpp

+#define MICM_ERROR_CATEGORY_CONFIGURATION "MICM Configuration"
+#define MICM_CONFIGURATION_ERROR_CODE_SUCCESS 0
+#define MICM_CONFIGURATION_ERROR_CODE_INVALID_KEY 1
+#define MICM_CONFIGURATION_ERROR_CODE_UNKNOWN_KEY 2
+#define MICM_CONFIGURATION_ERROR_CODE_INVALID_FILE_PATH 3
+#define MICM_CONFIGURATION_ERROR_CODE_NO_CONFIG_FILES_FOUND 4
+#define MICM_CONFIGURATION_ERROR_CODE_CAMP_FILES_NOT_FOUND 5
+#define MICM_CONFIGURATION_ERROR_CODE_CAMP_DATA_NOT_FOUND 6
+#define MICM_CONFIGURATION_ERROR_CODE_INVALID_SPECIES 7
+#define MICM_CONFIGURATION_ERROR_CODE_INVALID_MECHANISM 8
+#define MICM_CONFIGURATION_ERROR_CODE_INVALID_TYPE 9
+#define MICM_CONFIGURATION_ERROR_CODE_OBJECT_TYPE_NOT_FOUND 10
+#define MICM_CONFIGURATION_ERROR_CODE_REQUIRED_KEY_NOT_FOUND 11
+#define MICM_CONFIGURATION_ERROR_CODE_CONTAINS_NON_STANDARD_KEY 12
+#define MICM_CONFIGURATION_ERROR_CODE_MUTUALLY_EXCLUSIVE_OPTION 13
+
+#define MICM_ERROR_CATEGORY_JIT "MICM JIT"
+#define MICM_JIT_ERROR_CODE_INVALID_MATRIX 1
+#define MICM_JIT_ERROR_CODE_MISSING_JIT_FUNCTION 2
+
+#define MICM_ERROR_CATEGORY_PROCESS "MICM Process"
+#define MICM_PROCESS_ERROR_CODE_TOO_MANY_REACTANTS_FOR_SURFACE_REACTION 1
+
+#define MICM_ERROR_CATEGORY_PROCESS_SET "MICM Process Set"
+#define MICM_PROCESS_SET_ERROR_CODE_REACTANT_DOES_NOT_EXIST 1
+#define MICM_PROCESS_SET_ERROR_CODE_PRODUCT_DOES_NOT_EXIST 2
+
+#define MICM_ERROR_CATEGORY_RATE_CONSTANT "MICM Rate Constant"
+#define MICM_RATE_CONSTANT_ERROR_CODE_MISSING_ARGUMENTS_FOR_SURFACE_RATE_CONSTANT 1
+#define MICM_RATE_CONSTANT_ERROR_CODE_MISSING_ARGUMENTS_FOR_USER_DEFINED_RATE_CONSTANT 2
+
+#define MICM_ERROR_CATEGORY_SPECIES "MICM Species"
+#define MICM_SPECIES_ERROR_CODE_PROPERTY_NOT_FOUND 1
+#define MICM_SPECIES_ERROR_CODE_INVALID_TYPE_FOR_PROPERTY 2
+
+#define MICM_ERROR_CATEGORY_MATRIX "MICM Matrix"
+#define MICM_MATRIX_ERROR_CODE_ROW_SIZE_MISMATCH 1
+#define MICM_MATRIX_ERROR_CODE_INVALID_VECTOR 2
+#define MICM_MATRIX_ERROR_CODE_ELEMENT_OUT_OF_RANGE 3
+#define MICM_MATRIX_ERROR_CODE_MISSING_BLOCK_INDEX 4
+#define MICM_MATRIX_ERROR_CODE_ZERO_ELEMENT_ACCESS 5
+
+#define MICM_ERROR_CATEGORY_INTERNAL "MICM Internal Error"
+#define MICM_INTERNAL_ERROR_CODE_GENERAL 1
+#define MICM_INTERNAL_ERROR_CODE_CUDA 2
+#define MICM_INTERNAL_ERROR_CODE_CUBLAS 3


I like the categories, but I still worry that we could end up in a situation (not sure how), that we only have the integer value. What do #defines gain us over static const strings and one large enum class (for which we don't manually define the values)?

I could go either way. There is something about having one big bucket for things that makes me nervous, but I can't actually think of a real example of how this would be a problem in this case.

The one argument for #defines is that it allows this file to be included in fortran files as well, and might avoid some duplication or difficult passing of strings, but this isn't a super big deal.

I guess, my suggestion would be to keep the categories until we find ourselves in a situation where we only have the integer code for some reason and decide then if we should reorganize. What do you think?

K20shores · 2024-04-23T14:18:56Z

include/micm/util/error.hpp

+#if 0
+// Copyright (C) 2023-2024 National Center for Atmospheric Research,
+//
+// SPDX-License-Identifier: Apache-2.0
+
+// This file defines error categories and codes for MICM
+#endif


why this instead of #pragma once?

If we include this in a fortran file, any comments would have to be flagged with ! instead of //. This was just to get the CPP to remove these lines entirely

How about not including copyright for this specific file? I think that makes sense that we don't want to duplicate the error file for fortran but it could also be confusing for MICM being standalone CPP project to have this unusual usage of macro to cater for fortran. What do you think?

K20shores

Really like this. I left other comments but none of them would prevent this from being merged

mwaxmonsky

Looks great @mattldawson!

Nothing worth holding this up but we might want to expand on some of the error messages if it makes sense and use the std library to get the function name in one place.

The error messages might be duplicating the condition checks above them which isn't ideal but it might make things easier to debug at the user level if that can be exposed and reported back later.

include/micm/solver/jit_linear_solver.inl

include/micm/solver/jit_lu_decomposition.inl

include/micm/solver/jit_rosenbrock.hpp

include/micm/util/matrix.hpp

include/micm/util/vector_matrix.hpp

src/solver/rosenbrock.cu

mwaxmonsky

Thanks for addressing those comments @mattldawson!

WardF · 2024-04-23T21:14:32Z

Reviewing now as well, although I'm sure I'll be the slowest due to relative unfamiliarity; I don't anticipate finding any issues, but I'm trying to digest what I'm looking at instead of skimming it :)

boulderdaze

Looks great! Thank you for the work! I have one suggestion but it shouldn't prevent this branch from being merged.

boulderdaze · 2024-04-23T21:47:22Z

include/micm/util/error.hpp

+#if 0
+// Copyright (C) 2023-2024 National Center for Atmospheric Research,
+//
+// SPDX-License-Identifier: Apache-2.0
+
+// This file defines error categories and codes for MICM
+#endif


How about not including copyright for this specific file? I think that makes sense that we don't want to duplicate the error file for fortran but it could also be confusing for MICM being standalone CPP project to have this unusual usage of macro to cater for fortran. What do you think?

mattldawson · 2024-04-23T22:07:08Z

I agree about not making things confusing just to cater to fortran, but I think we should try to have the copyright and license on each source code file. What if we revisit this after the fortran wrapper is updated? It could be the case that we don't even need it in fortran and can just use normal comments.

mattldawson · 2024-04-23T22:10:24Z

I agree about not making things confusing just to cater to fortran, but I think we should try to have the copyright and license on each source code file. What if we revisit this after the fortran wrapper is updated? It could be the case that we don't even need it in fortran and can just use normal comments.

(I added this to our post-development review issue #211)

boulderdaze · 2024-04-23T22:10:46Z

I agree about not making things confusing just to cater to fortran, but I think we should try to have the copyright and license on each source code file. What if we revisit this after the fortran wrapper is updated? It could be the case that we don't even need it in fortran and can just use normal comments.

(I added this to our post-development review issue #211)

Sounds good, thank you!

mattldawson added 6 commits April 19, 2024 14:15

update error handling in config parser

04d2606

debug config error handling

b0089a3

debug config error handling

f2d76f6

finish updating to throw custom errors

9a119ac

Merge branch 'main' into develop-466-error-handling

a579556

fix merge conflicts

3dc57c1

mattldawson requested review from WardF, K20shores, boulderdaze and mwaxmonsky April 20, 2024 01:05

remove unused header

7cf2e07

K20shores reviewed Apr 22, 2024

View reviewed changes

WardF approved these changes Apr 22, 2024

View reviewed changes

boulderdaze approved these changes Apr 22, 2024

View reviewed changes

use common header for error codes and category names

2f5550b

K20shores reviewed Apr 23, 2024

View reviewed changes

K20shores approved these changes Apr 23, 2024

View reviewed changes

mwaxmonsky approved these changes Apr 23, 2024

View reviewed changes

mattldawson added 2 commits April 23, 2024 11:31

remove status struct from solver_config

16bafb9

add description to errors

e214cbe

mattldawson requested review from K20shores, WardF, boulderdaze and mwaxmonsky April 23, 2024 21:05

mwaxmonsky approved these changes Apr 23, 2024

View reviewed changes

WardF approved these changes Apr 23, 2024

View reviewed changes

boulderdaze approved these changes Apr 23, 2024

View reviewed changes

K20shores approved these changes Apr 23, 2024

View reviewed changes

mattldawson merged commit 0212b85 into main Apr 23, 2024
44 checks passed

mattldawson deleted the develop-466-error-handling branch April 23, 2024 22:10

Updates to error handling #468

Updates to error handling #468

Conversation

mattldawson commented Apr 20, 2024

codecov-commenter commented Apr 20, 2024 • edited Loading

Codecov Report

K20shores left a comment

Choose a reason for hiding this comment

mattldawson commented Apr 22, 2024 • edited Loading

WardF commented Apr 22, 2024

K20shores commented Apr 22, 2024

sjsprecious commented Apr 22, 2024

mwaxmonsky commented Apr 22, 2024

mattldawson commented Apr 22, 2024

WardF left a comment • edited Loading

Choose a reason for hiding this comment

mattldawson commented Apr 22, 2024

WardF commented Apr 22, 2024

WardF commented Apr 22, 2024

mattldawson commented Apr 22, 2024

mattldawson commented Apr 22, 2024

mattldawson commented Apr 22, 2024

mattldawson commented Apr 22, 2024

sjsprecious commented Apr 22, 2024

boulderdaze commented Apr 22, 2024

boulderdaze left a comment

Choose a reason for hiding this comment

mattldawson commented Apr 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

K20shores left a comment

Choose a reason for hiding this comment

mwaxmonsky left a comment • edited Loading

Choose a reason for hiding this comment

mwaxmonsky left a comment

Choose a reason for hiding this comment

WardF commented Apr 23, 2024

boulderdaze left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattldawson commented Apr 23, 2024

mattldawson commented Apr 23, 2024

boulderdaze commented Apr 23, 2024

codecov-commenter commented Apr 20, 2024 •

edited

Loading

mattldawson commented Apr 22, 2024 •

edited

Loading

WardF left a comment •

edited

Loading

mwaxmonsky left a comment •

edited

Loading