Post AJ4xMsVEFo5SLwsedU by johnpettigrew@ruby.social
(DIR) More posts by johnpettigrew@ruby.social
(DIR) Post #AJ4xMrycD400incbnk by jsrn@ruby.social
2022-05-03T14:34:15Z
0 likes, 0 repeats
I'm trying to catch `Net::ReadTimeout`s from a specific API and present a nice error message to the user. This API is used throughout the app, so I'd prefer not to duplicate this error handling code more than necessary.Is having a `rescue_from` in ApplicationController and checking the exception object to see if it originated in a certain class a clumsy way of doing that?
(DIR) Post #AJ4xMsVEFo5SLwsedU by johnpettigrew@ruby.social
2022-05-03T14:38:12Z
0 likes, 0 repeats
@jsrn Any reason not to use a custom exception rather than trying to sniff the origin of a standard exception type?
(DIR) Post #AJ4xMt79ymQcFacwl6 by jsrn@ruby.social
2022-05-03T14:39:54Z
0 likes, 0 repeats
@johnpettigrew Other than wishing there were a more elegant syntax for saying 'if this exception happens in this method, swap it out for this exception class', no, I suppose not. 😅
(DIR) Post #AJ4xMthJoLLs3jXp7Q by james@ruby.social
2022-05-03T15:16:41Z
0 likes, 0 repeats
@jsrn @johnpettigrew I think I'd go for this approach too -- wrap whatever might raise the `Net::ReadTimeout` in a method that you control, and raises a custom exception, and then `rescue_from` that custom one and display your nice message. That way you only have a single point to maintain if anything changes in whatever might raise `Net::ReadTimeout`, and you can choose nice descriptive names for your custom exception and method.
(DIR) Post #AJ4xMuH7fDzXqmIPvU by jsrn@ruby.social
2022-05-03T14:36:31Z
0 likes, 0 repeats
Alternative: catching original exception & raising a custom class closer to the source of the error, and then at least the intent in application controller is clear.
(DIR) Post #AJ4xUxVZWl2yC5tVE8 by jsrn@ruby.social
2022-05-03T15:18:10Z
0 likes, 0 repeats
@james @johnpettigrew That's what I've gone with. Thanks, gang! ❤️