-
Notifications
You must be signed in to change notification settings - Fork 10
/
0162.txt
406 lines (406 loc) · 18.6 KB
/
0162.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
예 안녕하세요 포프입니다
제가 저번에 이어 곧바로 또 요번에도 쉬지 않고
포프TV를 만들고 있어요 진짜 이런 게 오랜만인데
드디어 시간이 난 거겠죠
좀 인간처럼 살아 보자라고 이러고 있는데
날씨가 갑자기 안 좋아지고 있어요 밴쿠버에
그래서 아
좋은 시절 다 놓치고 비 올 때 추적추적할 때
시간이 남는구나 이 생각을 하고 있고
오늘은 exception 얘기를 좀 해 볼 것 같아요
제가 예전에 exception 얘기를
한 적이 있는지 없는지 모르겠어요
제가 이제.. 개인적으로 exception을
남용하는 걸 되게 안 좋아하거든요
그 이유를..
제가 말했었나? 기억이 안 나는데?
뭐..
안 했다면 댓글로 남겨 주세요
그럼 제가 다시 말하든가 할 텐데
그.. 중요한 거는
exception..
일단 뭐 제가 exception 안 좋아하는 이유 몇 가지 들면
사실은 예전에 제가 안 좋아하는 이유로..
저는 이렇게 계속 뭔가 뭔가 맘에 걸려서 되게
exception handling을 그렇게 안 좋아했는데
exception 자체도 그렇게 안 좋아했는데
그거를 한참 생각을 하다가..
아 예전에 이 얘기 하기는 했구나
예 했네요
그 Joel Spolsky, 그 아저씨가 쓴 블로그를 보고
아 내 생각과 되게 비슷하구나라는 걸 알면서
저보다 좀 더 체계적으로 정리돼 있는 걸 보고
아 내가 이래서 좀 더 싫어한 거구나라는 걸 좀 더 느꼈고
근데 뭐 exception이 반드시
필요한 경우가 있다는 것도 알아요
왜냐하면은
이 코드 자체가 내가 소유한 코드가 아닐 때
예를 들어서 뭐 서드파티 라이브러리에서
exception을 던진다거나
아니면은 예를 들어서
뭐 파일 IO나 뭐 이런 거 할 때
정말 제가 어떻게 컨트롤할 수 없는 상황에서
뭔가 fail을 해 버릴 때가 있잖아요
그럼 그럴 때는 이제 exception이 들어오는데
그럼 그거를 과연 어떻게 처리해야 되느냐
라는 게 되게 중요한 거 같아요
그냥
exception에 대한 이해가 없이 그냥 대충 쓰시는 분들
뭐 저도 이해가 확실하다고 생각하지는 않는데
잘 안 쓰니까
그런 분들은 그냥 대충 exception handling을 해 버려요
예전에 그 유영천씨..
유영천님이라고 해야겠구나
유영천님이 하셨던 말처럼 저한테 개인적으로
차라리 서버가 돌다가 exception이 나면은
그때 crash가 나면은 그때 고칠 수라도 있는데
이거를 exception handling해 갖고 그냥 막
대충 막 어떻게 돌리게 냅두다 보니까
나중에 한참 지나서 뻗어 버리는 거에요
그러면 이게 뻗었을 때
그 당시에 뭐 덤프 나온 거에도
예전 처음에 있던 문제가 나오는 것도 아니고
뭐 콜 스택이 제대로 있는 것도 아니고
한마디로 디버깅 정보가 없어서
디버그가 더 힘들어진다라는 얘기였거든요
굉장히 맞는 얘기에요
그래서..
제가 exception handling을
그 뒤에 굉장히 좀 많이 찾아봤어요
왜냐면 아이디어 자체는 굉장히 좋은 아이디어인데
언어에서 그거를 지원을 굉장히
이상하게 해서 제대로 쓰기도 어렵고
어찌 보면은
개념적으로 사람들이 쉽게 생각할 수 있는
그런 순차적인 구조 자체는 아니에요
왜냐하면은
예전에는 한창 exception 처음 나오고 막 사람들이
오 새로운 게 있다 그러고 남용을 하기 시작할 때는
void 함수 있잖아요 return 값이 없는 함수
아니면은 뭐 예전 언어들은 반환 값을
하나 이상 못 하는 경우가 많았으니까
그런 경우에 반환 값을 더 많이 할려면
함수 내부에서 exception을 던져 버린 다음에
그걸 호출자 있죠 caller에서 그거를 catch를 해 갖고
그 return 값을 받아 갖고 처리하는
그런 기괴한 패턴까지 나온 적 있었거든요
물론 아직도 쓰는 사람이 있어요
그렇게 쓰시는 분들 있으면 쓰지 마세요
그거 정말 잘못된 방법이에요
그러니까 exception의 문제가 크게 뭐였냐면은
제가 직접 그 함수의 코드를 따 보지 않는 한
어떤 exception이 던져지는지
찾기가 너무 힘들었던 거에요
그리고
그리고 보면은
아 코드를 이렇게 호출한 다음에 아 여기서
이런 exception도 발생할 수 있는데
이거를 처리해야 되는 것도
생각을 해야 되고 함수를 호출할 때마다
처리를 할 때도 과연 이게 올바로 처리하는 거냐
아니냐라는 것도 고민을 하게 돼요
어떤 경우에는 exception을 당연히 예측을 하고
이런 exception이 났을 때 아무 문제 없이 처리해 갖고
프로그램이 계속 돌게 해야 되는 경우도 있고
어떤 경우에는 그걸 logging을 쏜 다음에
아예 프로그램을 뻑나게 만들어야 되는 경우도 있고
여러 가지 예외 상황이 존재하는 거에요
그래서 뭐
뭐 Joel Spolsky 아저씨 같은 경우는
자기는 exception보다는 error 코드가 좋다
그래서 이제 옛날 C 스타일의 함수 보면은
exception은 없고 error 코드 반환하고
마지막 error가 뭐였는지 보는 이런 방식이 있잖아요
저는 그 방식이 좋다고 생각하는 이유는 뭐냐면
함수 signature를 보는 것만으로도
error 코드가 온다는 걸 알잖아요
그러면 그 error 코드를 가지고 어떻게
처리해야 될지를 생각을 할 수가 있어요
훨씬..
함수 속을 까 보지 않아도 알 수가 있어요
뭔가를 대비해야 된다는 거를
근데 exception 같은 경우는 함수 signature만
보고서는 웬만하면 알 수가 없으니까
물론 자바는 예외에요
하지만 뭐 자바는 죽어 가는 언어니까
그렇고
그래서 그게 문제였는데
어쨌든 간에 뭐 다시 얘기로 돌아와서
그래서 exception은 어떻게 handling
하는 게 좋은가를 열심히 찾아봤어요
근데 정말..
찾다 보니까 문제는 그거더라고요
exception을 어떻게 처리하는 게 중요한 게 아니었어요
exception이 났을 때
그 exception이 나든 말든 현재 프로그램의 상태가
고장이 나지 않는 게 제일 중요한 거였더라고요
그래서
이렇게
많은 문헌들을 찾아보면은 뭐
exception handling 이런 것도 있지만
또 다른 문헌을 보다 보면
위키피디아 페이지도 있는 걸로 알고 있어요
exception safe programming인가
exception safe handling인가 그런 얘기가 있어요
아마 programming인 것 같은데
한마디로 뭐냐면
코드가 진행 중에
한 줄 한 줄 진행이 되잖아요
그럼 여기가 exception이 났을 때도
이게 뻗든 처리를 하든 떠나서
현재 바꿀려고 하는 상태가 있잖아요
Object-Oriented Programming은 어차피
상태를 바꾸는 게 주 목적이니까
그 상태가 예전 상태에서 망가지지 않아야
되는 그런 원칙이 있어요 원칙이
그니까 exception을 던지는 코드를 짤 때
어느 순간에 exception이 나더라도
그 exception에 문제가 없이
코드는 그냥 상태가 변하지 말아야 된다
그니까 상태에 문제가 없어야 된다
그랬을 때 만약에 exception이 위로 올라갔을 때
누가 처리를 하더라도 내부 상태가 바뀌지 않으니까
원하지 않는 결론은 안 나온다는 거죠
근데 문제는 이게 정말 하기가 어려운..
그 뭐라 그러지
완벽하게 100% 이루기가 진짜 어려운 것 같아요
특히나 이제 뭐..
C++은 가능하다고 하는데
C# 같은 경우에는 exception이
내 프로그램 안에서만 나는 게 아니라
내 프로그램 외부에 있는
context에서 나고 들어오기도 한대요
제가 그런 상황을 보지는 못했는데 그냥 읽다가 봤어요
그래서 그런 상황까지 오면은
내 코드 기반이 아니고 내가 쓰는 라이브러리 기반도 아닌
것에 exception이 나 버리는 거를 제가 어떻게 하라고요
그래서 그게 이제
C#에서는 되게 어렵다
C++에서는 차라리 가능은 했는데
그래도 쉽지는 않았다라는 게
실제 마이크로소프트에 있는 그..
굉장히 유명하신 분도 있어요
이름은 제가 까먹었는데
중국계 사람인 것 같은데
그분도 이제 그런 얘길 했었고
Joel도 그런 얘길 했었고
근데 이제 문제는 현재 이제 웹 개발자들이
굉장히 Stack Overflow에 많은 관계로
그 사람들은 exception을 되게
신봉을 하고 좋아하긴 해요
근데
제가 exception을 많이 요즘 쓰는 결과 회사에서
진짜 제대로 exception handling하는 사람 별로 못 봤고
본인이 제대로 할려고 했어도 놓치는 게 되게 많아요
확실히 쉬운 건 아니고
그래서 요즘 가면 갈수록 저는..
뭐 아직 제가 그거 만들지는 않았는데
사실은 마이크로소프트 Code Contracts라는 게
그걸 좀 해 줘야 되는 것 같은데
아직 완벽히 완성이 안 된 라이브러리라
그건 나중에 뭐 좀 더 얘기를 제가 하겠고요
그래서 그게 없는 상황에서는
그냥 wrapper 하나 만들어서
Debug 상황에서는 차라리 assert를 넣어 갖고
중간에 그냥 멈추게 만들고
아.. 뭐라 그러지?
Release에서는 차라리 assert를 감추고
exception으로 바꾸는 방향을 생각을 하는데
그것도 쉽지가 않더라고요
뭐 C#이나 C++ 같은 경우에는 exception이 날 때
프로그램 breakpoint를 걸어주는 그런
디버그 툴도 있긴 하잖아요
그건 나쁘진 않은데
코드 기반이 방대해지면 서드 파티 라이브러리 쓰는 거
보면 막 걔네도 막 exception 막 던지고 이러다 보면은
거기 막 break 걸리면 하나하나 풀어 주는 것도 귀찮고
그래서 차라리 코드 레벨에서 정말
Debug, Release 갈리면서
assert 쏘고 exception으로 바꿔 주는
그런 것도 나쁘지 않다고 생각을 해요
하지만 제가 솔직히 생각하는 거는
exception은 정말 안 쓰고도 코드가
돌 수 있다면 안 쓰는 게 좋은 것 같아요
최대한 안 쓰고
뭐 error 코드로 처리하든 뭐로 처리하든 간에
뭐 예를 들어서 C#도 그런 거 있잖아요
integer parse할 때
int.Parse가 있고 int.TryParse가 있어요
int.Parse는 뭐 하는 거냐면
string을 숫자로 바꿔 주려고 하다가
그게 만약에 string이 다른 문자여 갖고
error가 나는 경우엔 exception을 던져요
그럼 저는 parse하다가 exception catch해 갖고
제가 어떻게 해야 되는 거고
TryParse는 return 값은 boolean이에요
그 parse가 성공했는지 안 했는지
boolean을 반환을 해 주고
parameter를 out parameter로 해서
제가 integer를 넣어 주거든요?
그니까 한마디로 이거는
말 그대로 error 코드 비슷한 개념이죠
그렇게 쓰는 게 실제 좀 더 빠르기도 하고
exception handling도 좀 비싼 거기도 하니까
그리고 코드를 보는 순간
아 TryParse가 boolean을 반환하니까
내가 이 boolean 가지고 성공했냐 안 했냐를 갈라서
뭐를 해야겠구나라는 게 딱 감이 오거든요
그래서 코드 readability도 좀 좋아지고
그래서 C#이나 이런 것들도 이제 점점 exception이 없는
버전을 많이 만드는 것 같아요 그런 내부 함수 쪽에서
그래서
저는 굉장히 바람직한 방향이라고 보고
아.. 뭐..
그래도 아까도 말했던 exception safe
코드를 짜는 거는 굉장히 좋은..
그니까
100% 짜는 게 아니라 그거에 대한 생각을 하면서
코드를 짜는 거는 되게 좋은 것 같아요
내가 어떤 상태를 세팅하고 파일을 읽는데
이 파일이 fail할 수가 있는 거에요
그러면 file fail 갖다 return을 해버리면
이미 상태가 바뀐 게 있잖아요
그럼 이 상태를, 파일에다 읽고 나서
이게 내 메모리에 올라온 다음에
그 다음에 처리를 해 주든
뭐 그래도 OutOfMemoryException은
또 있을 수 있겠지만
아니면은 그게 fail할 경우 뭐 try catch 잡아 갖고
그걸 원래 상태로 돌려주고 반환을 하는
이런 생각을 해 볼 필요는 있는 것 같아요
과연 이 코드가 여기서 fail하면, 저 코드가 여기서
fail하면은 이 프로그램 상태가 어떻게 되느냐
이 정도 생각은 어느 정도 해 주는 게 좋아요 확실히
근데 뭐 이게 은행 쪽이라든가
군사 쪽이라든가 이런 거면
정말 힘들게 생각을 해야 될 거고 100% 맞추기 위해
그게 아니라 뭐 게임 쪽이나 약간 좀
가끔 틀려도 되는 부분 있잖아요
그런 부분에서는 완벽히 100%는 아니어도
어느 정도까지 생각하면서 코드를 좀
짤 수 있어야 되지 않을까 생각이 들어요
그리고 막
제가 요즘 막 회사에서 도는 이상한 코드 중에
좀 실력 없는 애들 코드는 어떠냐면
exception이 어디서 발생하는지 개념도 없고
exception 어떻게 처리해야 되는지도 모르고
그러니까 아예..
그리고 exception 한 번 떴고 실행 중에
그러니까 아예 웹 API 호출 자체에
전부에 try catch 건 다음에 처음부터 끝까지
밑에 exception catch해 갖고
그냥 return 500이라든가
뭐 심지어는 OK 반환하는 애들도 봤고 WebRequest에서
그런 거 보면은 좀 한심하죠
왜냐하면은 뭐 integer 선언하는데
exception이 걸릴 경우도 없고
있나? 없을 거에요
뭐 int a 하는데 걸릴 경우도 없고
내부에서 처리하는데 웬만해서는
exception 걸릴 경우가 없거든요
결과적으로는 exception 나는 경우는
DB 긁을 때나 파일 긁을 때나 다른 웹 호출할 때나
아니면 정말 뭔가 코드에서 이상한 일 할 때 이 네 개인데
그니까 외부 dependency가 없는 한은 exception이
거의 안 난다고 생각을 하면 되는 거거든요
근데 그거 생각 안 하고 그냥 아 이게 빠르고 편하니까
모두 다 try catch, exception handling 하면은
나중에 exception 나도 어디서 났는지도 알기도 힘들고
코드 읽기도 드러워지고 로깅도 안 하고
그래서
차라리 exception 나고 throw 해 버리고 웹에서는..
그니까 로깅을 할..
자동 로그가 있다면 throw해 버리고
그 exception 메세지를 Debug 모드에서 차라리
화면에서 보는 게 편하거든요 웹 브라우저에서
그리고 이제 Release 모드에서는
꺼 버릴 수 있으니까 production 모드에서는
그런 것도 생각이 없고 그냥
코드는 일단 돌게 만들자 try catch 끝
이러는 그 자세 자체가 굉장히
제가 볼 때 프로그래머는 아니고
그러면은 거의 스크립트 정도 짜면서
이렇게 뭐 하는 정도가 아닌가
정말 코드가 어떻게 도는지
신경 안 쓰고 일단 돌게만 만들자
나중에 이게 문제가 되든 말든 나는 신경 안 쓰고
다른 사람이 뭐 고치겠지 이 개념일 수도 있고
좀 그런 거 보면 조금은 아쉽죠
그래서
제가 예전에 한번 어떤 프로그래머한테
자기가 좋은 프로그래머가 되고 싶다라고
얘기하는 사람한테 말해 준 적이 있어요
좋은 프로그래머가 될려면
니 코드 한 줄 한 줄에 이유가 있어야 된다고
그니까 누군가 와서 이 코드
왜 이렇게 짰어요라고 얘기했을 때
자기만의 이유가 있어야 돼요
나는 이래서 이렇게 짰다
그게 틀리든 옳든은 뭐 중요한 건 아니에요 사실은
왜냐면 사람마다 철학이 다르고
사람마다 추구하는 게 달라요
내가 옳다고 믿는 게 달라요
저는 뭐 읽기 편하고 좀
단순한 코드를 되게 좋아하는 반면에
어떤 사람들은 굉장히 아키텍쳐 잘 돼 있고
나중에 이게 막 천만 년이 지나도
extension 할 수 있는,
확장을 할 수 있는 그런 걸
더 중요시하는 사람도 있어요
저는 한 앞으로 5년 정도를
바라보고 코딩하는 사람이고
그래서 그런 거에 따라 코딩 철학도
달라지고 모든 게 달라지는데
최소한 이 코드를 누군가 물어봤을 때
내가 요 한 줄은 이래서 이렇게 짰다
라고 얘기를 할 수 있는 사람이
좋은 프로그래머가 될 수 있다고 생각을 해요
제가 심지어는 그런 얘기 듣거든요
이상한 코드 보면은 물어봐요
이 코드 왜 이렇게 짰냐고
그러면, 아 원래부터 딴 데 있던 코드
그냥 비슷하게 따라한 거야
그러면 저는 그건 잘못된 거라고 봐요
잘못된 코드 봤으면 고치는 게 프로그래머거든요 사실은
그리고 아니면 그게 틀렸다는 걸 알지만
이게 이래서 했다라고
말할 수 있는 사람도 중요한 사..
아니 그니까 뭐
당장 뭐 급해서라든가 이런
이유가 있어야 되는데 그게 없이
아 원래 그런 코드가 있었어 내 코드 아니야
이런 거는 되게 문제가 있다고 봐요
제가 터치한 부분은 내 코드가 아니어도 코드가
문제였으면 고쳐야 한다고 보거든요 어느 정도까지
아니면 뭐
아 당장 릴리스가 내일이어서 못 고쳤어라든가
그것도 괜찮은 방법인데
전혀 그런 거 없이 내 코드 아니야
원래 그런 거야 난 그냥 보고 베꼈어
이건 정말 좋은 프로그래머 못 되는 것 같고
코드 한 줄 한 줄에 제가 설명을 해야 된다 하면은
또 하나 문제가 뭐냐면
별로 안 좋은 프로그래머들 보면은
코드 스타일이 막 중구난방이에요
여기서는 뭐 이렇게 쓰고 여기선 저렇게도
전혀 상반되는 방식으로
그럼 그거는 한마디로 자기 철학이 없다는 거죠 아예
그냥 이때는 이러고 싶으니까 저렇게 쓰고
저때는 저러고 싶으니까 저렇게 쓰고
둘 중의 하나가 좀 상반되는 스타일이면
하나는 좀 안 좋은 스타일일 수도 있거든요
물어보면은
아 그냥 그렇게 했어
저건 그냥 그렇게 했어
그럼 이거 하나도 자기 혼자
통일을 못 시키는데 무슨
남하고 코드를 어떻게 짜고
남 코드를 어떻게 고칠 거고
이 사람들이 무슨 인터미디엇이 되고 시니어가 될 거에요
그래서 그런 것도 좀 많이 봤고
뭐 exception handling 얘기하다가 여기까지 왔는데
중요한 거는 아까 말씀드렸듯이 그냥
exception이 나도 문제가 없을 수 있는 코드를
만들려고 생각 정도는 해 보는 건 좋은 것 같다
그래요 그 정도로 급마무리하죠
예 포프였습니다