Если вы не перехватываете исключение, оно всплывает в стеке вызовов до тех пор, пока кто-нибудь не перехватит его. Если его никто не поймает, среда выполнения получит его и умрет с сообщением об ошибке исключения и полной трассировкой. IOW, вам не нужно явно перехватывать и повторно вызывать ваше исключение везде, что на самом деле лишило бы смысла иметь исключения. На самом деле, несмотря на то, что в основном используются для ошибок/непредвиденных ситуаций, исключения являются в первую очередь инструментом потока управления, позволяющим вырваться из нормального потока выполнения и передать управление (и некоторую информацию) в любое произвольное место в стеке вызовов.

Из этого POV ваш код кажется наиболее правильным (предупреждение: я не удосужился прочитать все это, просто быстро просмотрел), за исключением (без каламбура) для пары моментов:

Во-первых, вы должны определить свой собственный конкретный класс(ы) исключений вместо использования встроенного ValueError (вы можете наследовать от него, если это имеет смысл для вас), чтобы вы были уверены, что ловите только те исключения, которые ожидаете (довольно несколько уровней "под" ваш собственный код может вызвать неожиданную ошибку ValueError).

Затем вы можете (или нет, в зависимости от того, как используется ваш код) также захотеть добавить всеобъемлющий обработчик верхнего уровня в вашу функцию main(), чтобы вы могли правильно регистрировать (используя модуль logger) все ошибки и, в конечном итоге, освобождать ресурсы, сделайте некоторую очистку и т. д., прежде чем ваш процесс умрет.

В качестве побочного примечания вы также можете изучить и использовать правильное форматирование строк, и, по крайней мере, если производительность является проблемой, избегайте повторяющихся вызовов констант, таких как этот:

elif AnnotationUtil.is_embeddable_table(table) and AnnotationUtil.is_secondary_table(table):
    # ...
elif AnnotationUtil.is_embeddable_table(table):
    # ...
elif AnnotationUtil.is_secondary_table(table):
    # ...

Учитывая очень динамичный характер Python, ни компилятор, ни среда выполнения не могут безопасно оптимизировать эти повторяющиеся вызовы (метод мог быть динамически переопределен между вызовами), поэтому вам придется делать это самостоятельно.

РЕДАКТИРОВАТЬ:

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

Вы можете легко проверить правильность его работы с помощью простого MCVE:

def deeply_nested():
    raise ValueError("foo")

def nested():
    return deeply_nested()

def firstline():
    return nested()

def main():
    try:
        firstline()
    except ValueError as e:
        print("got {}".format(e))
    else:
        print("you will not see me")

if __name__ == "__main__":
    main()

Похоже, что программное обеспечение, поставляющее Python env, каким-то образом неправильно обрабатывает основной файл плагина. Похоже, мне придется проверить ребят из MySQL Workbench.

Угу... Даже встроенное ожидание механизма должно работать должным образом - по крайней мере, для той части стека вызовов, которая зависит от вашей функции main (не могу сказать, что происходит выше в стеке вызовов). Но, учитывая, как MySQL обрабатывает ошибки (а как насчет того, чтобы ваши данные усекались без вывода сообщений?), я не был бы особенно удивлен, если бы они взломали среду выполнения, чтобы молча передать любую ошибку в коде плагинов xD

Это нормально, когда ошибки всплывают

Исключения Python не проверяются, что означает, что вы не обязаны объявлять или обрабатывать их. Даже если вы знаете, что что-то может подняться, ловите ошибку только в том случае, если вы собираетесь что-то с ней делать. Хорошо иметь прозрачные для исключений слои, которые изящно прерываются, когда через них всплывает исключение:

def logged_get(map: dict, key: str):
    result = map[key]  # this may raise, but there is no state to corrupt
    # the following is not meaningful if an exception occurred
    # it is fine for it to be skipped by the exception bubbling up
    print(map, '[%s]' % key, '=>', result)
    return result

В этом случае logged_get будет просто пересылать любые KeyError (и другие), которые возникают при поиске. Если внешний вызывающий объект знает, как обработать ошибку, он может это сделать.

Итак, просто позвоните self.create_collection_embeddable_class_stub так, как вы это делаете.

Это нормально, если ошибки убивают приложение

Даже если ничто не обрабатывает ошибку, это делает интерпретатор. Вы получаете трассировку стека, показывающую, что и где пошло не так. Фатальные ошибки типа «происходит только при наличии ошибки» могут «безопасно» всплывать, чтобы показать, что пошло не так.

На самом деле выход из интерпретатора и утверждения также используют этот механизм.

>>> assert 2 < 1, "This should never happen"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AssertionError: This should never happen

Для многих служб вы можете использовать это даже при развертывании — например, systemd запишет это для системной службы Linux. Старайтесь подавлять внешние ошибки только в том случае, если безопасность является проблемой или если пользователи не могут обработать ошибку.

Можно использовать точные ошибки

Поскольку исключения не проверяются, вы можете использовать произвольное количество без перегрузки API. Это позволяет использовать пользовательские ошибки, сигнализирующие о разных уровнях проблем:

class DBProblem(Exception):
    """Something is wrong about our DB..."""

class DBEntryInconsistent(DBProblem):
    """A single entry is broken"""

class DBInconsistent(DBProblem):
    """The entire DB is foobar!"""

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

try:
    gen.generate_classes(catalog)
except DBEntryInconsistent:
    logger.error("aborting due to corrupted entry")
    sys.exit(1)
except DBInconsistent as err:
    logger.error("aborting due to corrupted DB")
    Utility.inform_db_support(err)
    sys.exit(1)
# do not handle ValueError, KeyError, MemoryError, ...
# they will show up as a stack trace