Enum to int mapping is conceptually undefined, even though many languages support one way or another. Enum 'ERROR' is just that - 'ERROR'. If you choose to assign it a numeric value, the mapping is up to you. Enums conceptually also do not have relation between values. ERROR is different from WARNING, yet neither is greater as far as enums go.
Even without taking C++'s int/enum equivalence, your use of enums is not suitable for the purpose.
IMHO, the following is how the API should be used in this particular case:
void Error( std::string file, int line, std::string text1 = "", std::string text2 = "", ErrorGrade g = ErrorGrade::None );...Error("File.cpp", 17, "", "");Error("File.cpp", 17, "", ErrorGrade::Terminate);Error("File.cpp", 17, "", ErrorGrade::Terminate || ErrorGrade::MessageBox);
How the above is implemented depends. Values could be simple ints, or they could be more complex classes. The ErrorGrade above can be polymorphic as well, implementing the error behavior by itself. This design is more representative for values which can be combined (noncritical = 00, terminate = 01, terminate+box = 11, consequently just box = 10).
Alternatively, if grades are ordered, then providing a wrapper that defines order, as well as strong type safety will be better solution.
Given real world use, I'm consistently disappointed with enums and can't think of many uses for them, even in other languages. They reek too much of hardcoding. If they define functionality, then there are other ways to implement it (polymorphism, parameters). If they define data, then the data will often be best served from outside. And if for error or labeling, then const int values do the job, even if wrapped in some class.