minimum knapsack

[Mathemalsky]

This is the first algorithm in where we could enter the case of an infeasible instance. Do you think we should introduce own error types for that purpose inheriting from the errors from std::except?

[MilchRatchet]

Do you think we should introduce own error types for that purpose inheriting from the errors from std::except?

I think we should not throw errors at all but rather return that the result is "infeasible". If I am not mistaken, an error ends the application right? If we simply return infeasibility then the user can decide on his own what to do with it. I had not thought about that in the previous algorithms but I think throwing errors in such a library is simply bad design.

[Mathemalsky]

Do you think we should introduce own error types for that purpose inheriting from the errors from std::except?

I think we should not throw errors at all but rather return that the result is "infeasible". If I am not mistaken, an error ends the application right? If we simply return infeasibility then the user can decide on his own what to do with it. I had not thought about that in the previous algorithms but I think throwing errors in such a library is simply bad design.

No on that point you are mistaken. Errors are introduced exactly for that purpose: Reporting that something went wrong and you can decide how to deal with that information. Stopping the application is only the default if you don't use the error information. This page gives a good overview of exceptions: https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-160

But I'm not sure what happens if a c program receives an error from a c++ library since as far as I know there is no error handling in c.

[MilchRatchet]

Do you think we should introduce own error types for that purpose inheriting from the errors from std::except?

I think we should not throw errors at all but rather return that the result is "infeasible". If I am not mistaken, an error ends the application right? If we simply return infeasibility then the user can decide on his own what to do with it. I had not thought about that in the previous algorithms but I think throwing errors in such a library is simply bad design.

No on that point you are mistaken. Errors are introduced exactly for that purpose: Reporting that something went wrong and you can decide how to deal with that information. Stopping the application is only the default if you don't use the error information. This page gives a good overview of exceptions: https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-160

But I'm not sure what happens if a c program receives an error from a c++ library since as far as I know there is no error handling in c.

I see, so there is a try/except/finally kind of way of error handling. I had a look at it and it seems that the internal implementation of throwing and catching is based on the compiler and in fact, throwing an error is not even necessarily cross compatible over different compilers. Things apparently get even worse once you mix different operating systems or languages. Also you are right when you say that C and other languages have no error handling like that. Those languages would not be able to catch the errors. Thus I would guess not throwing an error and instead signaling this in the return value seems to be the correct way.

Afterall, if I look at different libraries I have used in the past (outside of C#) they have always returned some special value instead of throwing an error.

[Mathemalsky]

Do you think we should introduce own error types for that purpose inheriting from the errors from std::except?

I think we should not throw errors at all but rather return that the result is "infeasible". If I am not mistaken, an error ends the application right? If we simply return infeasibility then the user can decide on his own what to do with it. I had not thought about that in the previous algorithms but I think throwing errors in such a library is simply bad design.

No on that point you are mistaken. Errors are introduced exactly for that purpose: Reporting that something went wrong and you can decide how to deal with that information. Stopping the application is only the default if you don't use the error information. This page gives a good overview of exceptions: https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-160 But I'm not sure what happens if a c program receives an error from a c++ library since as far as I know there is no error handling in c.

I see, so there is a try/except/finally kind of way of error handling. I had a look at it and it seems that the internal implementation of throwing and catching is based on the compiler and in fact, throwing an error is not even necessarily cross compatible over different compilers. Things apparently get even worse once you mix different operating systems or languages. Also you are right when you say that C and other languages have no error handling like that. Those languages would not be able to catch the errors. Thus I would guess not throwing an error and instead signaling this in the return value seems to be the correct way.

Afterall, if I look at different libraries I have used in the past (outside of C#) they have always returned some special value instead of throwing an error.

So our way to go is including an status int in the structs we return?

[MilchRatchet]

Do you think we should introduce own error types for that purpose inheriting from the errors from std::except?

I think we should not throw errors at all but rather return that the result is "infeasible". If I am not mistaken, an error ends the application right? If we simply return infeasibility then the user can decide on his own what to do with it. I had not thought about that in the previous algorithms but I think throwing errors in such a library is simply bad design.

No on that point you are mistaken. Errors are introduced exactly for that purpose: Reporting that something went wrong and you can decide how to deal with that information. Stopping the application is only the default if you don't use the error information. This page gives a good overview of exceptions: https://docs.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-160 But I'm not sure what happens if a c program receives an error from a c++ library since as far as I know there is no error handling in c.

I see, so there is a try/except/finally kind of way of error handling. I had a look at it and it seems that the internal implementation of throwing and catching is based on the compiler and in fact, throwing an error is not even necessarily cross compatible over different compilers. Things apparently get even worse once you mix different operating systems or languages. Also you are right when you say that C and other languages have no error handling like that. Those languages would not be able to catch the errors. Thus I would guess not throwing an error and instead signaling this in the return value seems to be the correct way. Afterall, if I look at different libraries I have used in the past (outside of C#) they have always returned some special value instead of throwing an error.

So our way to go is including an status int in the structs we return?

Yes.