Как изолировать Вашу программу от вызовов до “плохого” API?

Ответы @S.Lott и @Stephen C точны в отношении того, как справляться с подобными ситуациями, но я бы хотел добавить, что в неакадемической среде вы также следует попытаться заменить API как можно скорее. В ситуациях, когда мы застревали в плохом API, обычно из-за выбора продаваемого решения по другим причинам, я со временем работал над заменой функциональности моей собственной. Ваши клиенты не будут такими терпимыми, как ваш профессор, поскольку им на самом деле придется использовать ваше программное обеспечение (или нет!), А не просто оценивать его.

Конечно, существуют ситуации, когда использование клейкой ленты является адекватным выбором для решения проблемы . Однако, когда это приводит к такому плохому поведению, как вы описываете, лучше не полагаться на это слишком долго и начать работу над настоящим ремонтом.

Я большой поклонник отдельных процессов для такого рода вещей.

Создайте подпроцесс и дождитесь результатов.

Если API не является детерминированным, введите поток таймера в оболочке, которая превращает плохой API в основную программу.

Таким образом, подпроцесс всегда заканчивается в заданное время. Это либо дает полезный результат, либо код выхода системы, указывающий на сбой.

Лучшее , что можно сделать, - это повторно реализовать рассматриваемый API. Однако, как вы говорите, это очень тяжелое и, вероятно, выходящее за рамки решение.

Следующим вариантом было бы обернуть API, если это возможно. По сути, если вы можете заранее определить, что именно вызывает сбой в наборах данных, вы можете отклонить вызовы, чтобы гарантировать детерминизм. Не похоже, что это сработает и для вас, поскольку вы предполагаете, что повторный вызов с тем же набором данных иногда завершается, если он бесконечно зацикливался в предыдущем вызове.